If your application is very performance sensitive using an outside array
container is most likely going to significantly faster than IBO's buffering
operations.

I imagine you could try it both ways and measure the difference.

I have been pretty careful in IBO to ensure I have not created performance
problems in its management of the dynamic data structure but it is just that
and not an array. I cannot use mathematical operations with pointer magic to
deliver up data. I have a (kind of) doubly linked list of nodes with 5
maintained references within it and some maintained index lists isolating
specific nodes I want to group specially.

When searching for a record by bookmark I scan keys which are stored as
fixed length raw data and there is nothing but pointer walking and binary
peeking required to find the record of interest. I also have some
interesting algorithms using the 5 references to make sure it doesn't
blindly walk the whole list, and so far as I know, it generally comes up
with a match very quickly and efficiently every time, unless you are coming
out of the blue with something. As yet, I have not felt a need to maintain a
binary tree for fast node searching due to the great expense this would
impose when fetching records and introducing them into the structure.
Inserting into a doubly linked list is just about as cheap as it gets. If I
do add a binary node tree I will simply invalidate it every time a node is
changed in some way and put that node in a work queue, then I will use idle
CPU cycles to do a fixup or in an on-demand manner do the fixup. So far, no
need for this seems apparent.

When searching by non-key data this gets more complex. I store the data in a
variable length compressed state which requires it to be read into a buffer
for viewing. I can't just directly scan nodes and peek at buffers directly.
This makes that considerably more slow than key based lookups. The allocated
memory savings are a huge gain in doing this but it does have its price in
full record scanning performance. Depending on the connection protocol I
influence the Locate() operation to sometimes just perform a query on the
server and bring back the associated key and then do a key based search
which in many instances is quite helpful to improve efficiency.

The tricky part in doing this was also making sure I integrated
CachedUpdates properly since records in the buffer may not match the records
on the server. I maintain a threadlist (meaning a separate linked list of
node reference pointers) of nodes impacted by cached updates and give them
special consideration.

Geoff says he gets lost easily in the code for all this stuff (which I find
hard to imagine).
I'll admit it's quite a mishmash of algorithms but I've sure had fun doing
it...

Anyway, I think this gives you a little more of an idea what you are up
against.

Helen, feel free to include this in the FAQ somewhere. Not that it will help
anyone use IBO better, it is nice to know the guts of your tools for
application design considerations.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "georgethenorge" <ghelmke@...>
To: <IBObjects@yahoogroups.com>
Sent: Tuesday, April 16, 2002 11:37 AM
Subject: [IBO] TIB_Query buffer speed


> One of my performance increasing tricks has been to take a query and put
the contents in an array. Then, I do all of my operations on the array, and
put it back in the query when I am done. This works well for a GUI where
the user is jockeying 100 different elements around the screen.
>
> What I am wondering is - what are the performance differences between this
and just using a TIB_Query as is, with locates, etc?
>
> I would assume that writing would be slower, because of the overhead
involved in actually posting the changes to the server.
>
> What about reading? How does that compare?
>
> If you know the index of an array, you can get to that particular element
in no time. Is there some way to use the buffer in TIB_Query in a similar
fashion with the KeyLinks parameter?
>
> Thanks
>
> George Helmke