Mellroth Posted September 30, 2006 Report Share Posted September 30, 2006 I don't think that create/dispose methods are that critical, you only do this once, but the get/set methods are called more often. To make create methods more or less independant of the number of elements in the array, one can implement a linked list that holds indices of the free elements, and points to the next. To create a new pointer, only remove first element from that list, i.e. no search for next free element. Dispose then adds free pointer to the end. I'll see if I can find some old linked list implementation on my disks. /J Quote Link to comment
bsvingen Posted September 30, 2006 Author Report Share Posted September 30, 2006 I don't think that create/dispose methods are that critical, you only do this once, but the get/set methods are called more often.To make create methods more or less independant of the number of elements in the array, one can implement a linked list that holds indices of the free elements, and points to the next. To create a new pointer, only remove first element from that list, i.e. no search for next free element. Dispose then adds free pointer to the end. I'll see if I can find some old linked list implementation on my disks. /J The get/set methods are already O(1) since it is just ordinary array indexing. A made a binary search tree from the pointers to test the performance against Variant attributes. Acording to aristos Variants use a read black binary tree to store/find named atributes. Attributes, as native LV objects (and using a red black tree) will be faster by a factor of 3. The performance in LV8.2 will be about 50% better for both attributes and the binary tree (attached is the 7.1.1 version). Download File:post-4885-1159604035.zip Quote Link to comment
bsvingen Posted October 1, 2006 Author Report Share Posted October 1, 2006 Of course, in making a call by ref LVOOP you need a get-modify-set pass. Then you need to protect that *pass* so that no other VI tries to set while it's being modified etc. But that is, as far as I can see, the only time you will ever need such protection, and it is a very peculiar construct and is probably more of a typical example how NOT to use pointers. In other programming languages there would be no need for such a pass, because the data is edited directly. Still, i wonder how often, if ever, you will modify the same instance at different places simultaneously. Will this ever become a real issue, or is it more of an academic problem? In the other general ref, i have been experimenting with occurences. There I set an occurence for each pointer, each time data is set so that data can be read in another loop for arbitrary pointers fully synchrounous (similar to queue). This can be done with seemingly no performance penalty (to set the occurence), and i wonder therefore if it will be possible to do some similar for the pass. An occurence can for instance be set each time a pass is finished, and the pass will never start before an occurence has been acquired. One problem is what to do for the first ever pass. Quote Link to comment
LAVA 1.0 Content Posted October 1, 2006 Report Share Posted October 1, 2006 Of course, in making a call by ref LVOOP you need a get-modify-set pass. To increase the performance of get-modify-pass sequence I wrote a semaphore based on the ideas of besvingen's pointer system. I submitted it to the repository, it'll appear if the admins accept it. Quote Link to comment
Mellroth Posted October 2, 2006 Report Share Posted October 2, 2006 bsvingens original idea is just a way to have several LV2 globals accessed by reference, but still it is just globals. If you need locking/protection etc. then GOOP is the way to go. In fact, if you add locking mechanism to this LV2 global, then you are getting very close to the GOOP versions based on uninitialized-shift-registers. I'm not saying that it is bad to add protection to this implementation; I'm just saying that there is room for both. If you are planning to use this system as a general LVOOP core you might want to make the core VI reentrant, and wrap that in a non-reentrant VI (specific to each class). Otherwise you will have a dependency between classes, since method calls from different classes might collide. /J To increase the performance of get-modify-pass sequence I wrote a semaphore based on the ideas of besvingen's pointer system. I submitted it to the repository, it'll appear if the admins accept it. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.