bsvingen Posted August 24, 2006 Report Share Posted August 24, 2006 File Name: General reference system File Submitter: bsvingen File Submitted: 11 Sep 2006 File Updated: 18 Sep 2006 File Category: LabVIEW OOP (GOOP) An LVOOP class that creates and controls reference-data pairs. The basic idea is to simulate random access memory and malloc()/free() by using one single LV2 style global. The data can be of any type (including any LVOOP class and strict typedefs) and can be allocated in any order. The only restriction to the number of references is the physical memory on the computer. The global stores data in a Variant Array and uses a separate Bool Array to control access and free/protect the data. The "address" to the data that is stored in the reference (LV Object) ,is the index in the Variant Array where the data is stored in the LV2 Global. By using Variant as the type, it is possible to get a reference to all types, and there is no need to manually change a typedef and possibly the names for every vi when more than one typedef will be used. A small performance penalty is introduced due to the type conversions to/from Variant. However, due to the inherent effectiveness of LV2 style globals, this method is still 2-3 times faster than an equivalent scheme made with wrappers around queue primitives, but slightly slower than using queue primitives directly, (no wrappers around the queues, see example provided). For an even faster reference system, twice the speed of queue primitives, se the separate "Pointer System" on this Code Repository. In contrast to queues that can be regarded as synchronous references to data, this reference system is fully asynchronous. Allocation and freeing of data is done dynamically. Allthough this reference system may at first glance have some resemblence to "classic" GOOP, it is by no means a GOOP system. The main purpose of the reference system is to have a fully asynchronous and fully reusable system for read and write access to one single instance of data in more than one place. All the VIs in the library are documented. Click here to download this file Quote Link to comment
bsvingen Posted August 24, 2006 Author Report Share Posted August 24, 2006 To get an idea of the performance of the LV2 style reference system i have made some test cases using the dqGOOP test cases as templates. In contrast to what i wrote last night, it IS possible to create arrays from clusters with strings (i have no idea why it didn't work list night, i got a strange error saying that LV could not determine the wire type, maybe that was in LV8 because i started with that?? all these test cases are for LV8.2). There are 6 test cases, dqGOOP(locked), dqGOOP, variant global ref, string global ref, LVOOP global ref and a "specific" ref for the actual strict type def cluster. They are all similar in performance except for the locked dqGOOP which is much slower. There is little penalty in using variant compared to using a specific typedef (only about 30% slower in set), and there is no practical difference between variant vs string. dqGOOP (unlocked) have a few percentages better performance in get/set, but the global refs are fully asynchronous. Download File:post-4885-1156428559.zip Quote Link to comment
bsvingen Posted August 24, 2006 Author Report Share Posted August 24, 2006 Here is another version of the general Variant reference system. In this version it is not neccesary to preset the LV2 global. The arrays will grow according to the number of refs that are created. It is initiated at first use. This means that the LV2 global is completely invisible, it just hangs in the in memory somewhere and do it's job. I allso don't think it is realy nessesary to de-initialize the global, because LV will take care of that in any case when the program finishes. However, it is made so that it still can be initialized if that is wanted. Download File:post-4885-1156455614.zip Quote Link to comment
bsvingen Posted August 25, 2006 Author Report Share Posted August 25, 2006 Well, it doesn't seem like this is of outmost interest for many people here , but i think i'm converging towards something useful. I have done some changes to the core LV2 Global. It is dynamic, but there are also minor internal changes that, in some strange way probably due to some LV memory handling/buffer allocations ??, improves performance quite a lot. I have also made the LVOOP different so that it takes Variants as input. I have renamed it to Pointer Class, because i think that is a better description, and i have added some pointer aritmetics (can be used for very cool, but buggy? code). When using LVOOP for the pointer, and Variants for the data, the performance increases even more. A simple by ref GOOP made from this pointer class is almost twice as fast as dqGOOP in get/set, and up to 16 times faster than the locked dqQOOP class (get). So, im converging toward the pointer class. It is fastest, it makes pointers/references to *anything* including LVOOP Objects, It is much more secure, because the LV2 Global is protected (only member functions can call the global) and the pointers/reference - wires can only be used by the member functions. It is also more elegant than the others IMO. Download File:post-4885-1156527660.zipDownload File:post-4885-1156527684.zip Quote Link to comment
bsvingen Posted August 26, 2006 Author Report Share Posted August 26, 2006 Here is another variant. This is a pure object pointer. It will make a reference-data pair to any LVOOP Object that is sent to it, othervise it is exactly the same as the last one. Download File:post-4885-1156603068.zip Quote Link to comment
bsvingen Posted August 28, 2006 Author Report Share Posted August 28, 2006 I have updated the pointer system a bit. This version is made for a strict typedef (see project explorer). I have also included a linked list that is made with this pointers. A linked list consist of a structure (a cluster) that has one or more pointers that point to other clusters of the same kind. With linked lists one typically can build trees, stacks, hash tables and all kinds of dynamic structures. A linked list is fully dynamic and exist entirely hidden in memory except for the single starting node. The funny thing is that when building this linked list with the pointer system, one get a list that fully (as far as i can see) adheres to data flow principles (as can be seen in the BD, although it is only the single starting point that flows). Download File:post-4885-1156792100.zip Quote Link to comment
Mike Ashe Posted September 11, 2006 Report Share Posted September 11, 2006 Do you have any examples of using this to implement linked lists yet? That and Data Tree structures would seem to be logical uses for your toolkit. Thanks for posting! Quote Link to comment
bsvingen Posted September 11, 2006 Author Report Share Posted September 11, 2006 Do you have any examples of using this to implement linked lists yet? That and Data Tree structures would seem to be logical uses for your toolkit.Thanks for posting! I have one example in the other thread here. It is the last one called Pointers Typedef V02.zip and can quiclly be modded to variant type. However, i think a linked list class would be made in a more elegant manner directly into the global using the same technique as the reference global, but with two extra arrays inside used as pointers to "next" and "previous" (for a doubly linked list or binary tree). Quote Link to comment
Michael Aivaliotis Posted September 11, 2006 Report Share Posted September 11, 2006 Moderators Note: I've merged the original post and this new Code Repository thread into one. Discussions can continue in this new thread. I've also attached some files that were in the first post of the original thread. Download File:post-2-1158006786.zip Download File:post-2-1158006772.zip 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.