David Johnson wrote:

>Given that Firebird's wire protocol is a known bottleneck, anything that
>reduces that data transmitted (time spent) on the wire will improve
>performance. We can blame Borland for a crummy wire protocol, but we
>don't have to be tied to Borland's past mistakes.
>

I designed most of the wire protocol, actually. Borland just extended
it to pass dynamic SQL, which had originally been purely client side.
The wire protocol, although there is room for improvement, isn't really
the bottleneck. The biggest problem is the number of time data has to
copied and converted as it snakes it way through the layers of
plumbing. The number of round trips is dictated by the API definition
that specifies that each call has a status return. We can do a denser
encoding and eliminate intermediate conversions, but that's not going to
have a striking effect on network throughput.

I don't find batching as exciting as some other people do. Yes, it may
reduce the number of round trips, but at the expense of application
program complexity. If somebody want to explain why batching sql
statements is the best thing since sliced bread, I'm all ears.

>Batching is becoming a quasi-standard feature since it is explicitly
>supported as an option (not a requirement) in the JDBC interface
>specification.
>
>Of course, it may not be reasonable to do this without serious rewrite.
>I would suggest leaving documented hooks for future extensions in the
>Vulcan rewrite, then there is a place for the _optional_ extension,
>should someone in the future want to take up the feature after the wire
>protocol has been revamped.
>

Hooks are bad things. They rarely become useful and more often impede a
good solution. It is always better to understand what you need and
design to those requirements. A clean, minimal design is almost always
easier to extend than one that includes all sorts of half baked ideas in
hopes that they might be useful some body.