--- In Firebird-Java@yahoogroups.com, "Roman Rokytskyy"
<rrokytskyy@a...> wrote:

> > should never hit a prepare during operation.
>
> Then maybe this behavior is ok. I was just surprised that removing

the TCP

> stack brought only 13% on a data intensive application.
>
> Roman

I am not too surprised - My cache maintenance is very sloppy, opting
for the BIBF (Bloody Ignorance and Brute Force) approach. On the
other hand, I have become quite adept at limiting TCP traffic (pause
to pat myself on back, then trip and fall flat on my face...).

Any time I do a commit, and there is data in the backing store that
is not in the cache, I rebuild the cache using "Select * from table
order by ID", where ID is the primary key of the table. If I overrun
the cache, I expect performance to degrade and the workload on
Firebird to grow enormously.

I wasn't too concerned about doing the math for best caching
algorithm because the intent is ultimately rewrite this in C++ and
try to embed it where it can work directly with the Firebird engine's
internal row buffering.

Also, we might be seeing the heavy garbage collection that I was
warned about earlier.

I'm in the middle of that nasty install that's been occupying my life
for the last nine months, so it may be a bit before I can return to
this.