Very large variable

6 views
Skip to first unread message

Cedric Fontaine

unread,
Nov 26, 2009, 10:34:07 AM11/26/09
to OpenQM
Hello,

We're working on very large variables (300 000 bytes) and it seems too
heavy for QM to work on this large variable and so time is exponential
when adding data to this big variable.

Is there any optimization on QM part we can do to work faster with
big items ?

Martin Phillips

unread,
Nov 26, 2009, 10:49:52 AM11/26/09
to ope...@googlegroups.com
Hi Cedric,

Please explain a bit more about how you update this variable. We regularly
work with data of this size and bigger with no problems.


Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200

Cedric Fontaine

unread,
Nov 26, 2009, 1:46:54 PM11/26/09
to ope...@googlegroups.com
Martin Phillips wrote:
> Hi Cedric,
>
>> We're working on very large variables (300 000 bytes) and it
>> seems too heavy for QM to work on this large variable and so
>> time is exponential when adding data to this big variable.
>>
>> Is there any optimization on QM part we can do to work faster
>> with big items ?
>
> Please explain a bit more about how you update this variable. We regularly
> work with data of this size and bigger with no problems.

It is an item we read and then on a very large attribute we are doing
locate, insert and delete.

--
Cedric Fontaine
http://www.terroirsquebec.com

Brian Speirs

unread,
Nov 26, 2009, 2:53:17 PM11/26/09
to OpenQM
In general, multi-value systems can run run into speed issues when
dealing with large dynamic arrays - but it depends on the
optimisations built into the language and on how you are using it.

Long, long ago, in a galaxy far away, MV databases used to count down
the dynamic array whenever you accessed the variable. This made many
operations slow once you got over say 1,000 attributes.

More modern implementations keep a pointer to the last part of the
dynamic array accessed. This makes operations around the same point of
the dynamic array much quicker. Likewise, append operations are fast
and almost independent of size.

So, if you are using LOCATE in a random fashion within a large dynamic
array, I would expect the speed to be variable. On the other hand, if
all the operations are moving steadily along the array (and it is
sorted), then the speed should be fast.

If you are using DEL or INS in the middle of a large dynamic array ...
well, I don't know. Each of those breaks the dynamic array into two,
and rejoins the parts, so it *might* be quick. Martin will need to
comment further there.

But, it may be helpful if you gave a more complete explanation of the
issue you are experiencing, and just how you are manipulating the
dynamic array.

Cheers,

Brian

Martin Phillips

unread,
Nov 27, 2009, 4:21:08 AM11/27/09
to ope...@googlegroups.com
Hi Brian/Cedric,

> More modern implementations keep a pointer to the last part of the
> dynamic array accessed. This makes operations around the same point
> of the dynamic array much quicker. Likewise, append operations are
> fast and almost independent of size.

We do something very much like this. We are investigating some performance
issue in management of large strings but the general perception of our users
appears to be that we do not have a significant problem.

Reply all
Reply to author
Forward
0 new messages