Preface

Why do we need another GOOP framework?  The short answer is simply due to performance.  Most of the existing GOOP examples involve classes with relatively few objects that get created at the application initialization and destroyed at the end.  What if you want to build an application applying OOP principals where there are hundreds or even thousands of objects and the design entails that one object may contain multiple other objects which in turn contain objects themselves?

I started to develop such an application and soon ran into the performance limitations of the existing GOOP frameworks.  I started with the original GOOP toolkit that was developed by Endevo and is available from the NI website.  After having some performance issues, I tried to look at the code and ran into the password protected core VI.  I then investigated other GOOP options and found openGOOP on the OpenG website.  Unfortunately, the performance was much worse for creating and destroying objects.  After some investigation it was apparent that the bulk of the performance hit was from the "Open VI Reference" call which creates the data store for the object.  Since this was the basis of the OpenGOOP framework, I was at a dead end until...

There was an offhanded comment on the Info-LabVIEW mailing list about how the queues in LabVIEW were improved in LabVIEW 7.  Then I started to poke at the concept of using a queue as the data store for GOOP objects.  Not only is the access fast, but queues have built in locking which means there is no need to create Semaphores or Occurrences.  I used the new "Show Buffers..." tool and focused on creating the dqGOOP VIs with one priority...PERFORMANCE.

If you need to make GOOP classes that have fast performance, then the dqGOOP Toolkit is the solution for you.