Yah, in the JDBC adapter layer I wrote I now break up batched statements
if they're greater than a certain (configurable) size.
I don't want the application code to know or care that there is a limit,
if at all possible. I could use a Value List Handler, to pull stuff
across in manageable chunks, but I don't have any code for that which I
could reuse.

I'll file a bug on Thursday, thanks for your help.

-----Original Message-----
From: Roman Rokytskyy [mailto:rrokytskyy@...]
Sent: Tuesday, March 15, 2005 5:48 PM
To: Firebird-Java@yahoogroups.com
Subject: Re: [Firebird-Java] Maximum number of items in batch

> I'll see if I can link in a free profiler when I get a chance. I'm
> guessing the problem is b.
>
> One free improvement would be the result list (and the batch list):
> http://soft.killingar.net/documents/LinkedList+vs+ArrayList
> ( the relevant line in the following graph is ArrayList best-case, as

we

> know the size to preallocate)
> http://soft.killingar.net/docs/LLvsAL/graph.pdf
>
> Try:
> List results = new ArrayList[batchList.size()];
>
> There is less memory overhead (ArrayList doesn't store pointers to
> previous and next), memory allocation is more efficient (it's all done
> at one time), and it's fail-fast (if there isn't enough memory, it'll
> fail at the beginning before doing any more work)[of course, this
> ignores the memory allocated with each new Integer].

True, I should have used ArrayList, or even int[]. However we are
talking
about improving the memory usage from 8 to 24 bytes per item in batch,
in
your case something ~3 MB. The storage of that 160,000 items takes at
least
something ~300-500 MB (or maybe even more). If your application is
crashing
because of not being able to allocate 3 MB right after allocating
300-500
MB, I would first consider reviewing the application.

Anyway, please fill the bug report and I will clear that place in the
next
version.

> BTW, is backupVars being used?

Nope. Some refactoring artifact. 24 bytes more.

Roman




Yahoo! Groups Links