Gustav Trede wrote:
> Kris Jurka skrev:
>> The rowBuffer copy is only needed for updateable ResultSets, so we
>> could probably wrap all those calls with isUpdateable() { }. Are you
>> seein a significant performance impact from those calls or are you
>> just curious?
>>
>
> its good news that its avoidable.
> I buffer roughly 2Gbyte of data by jdbc in RAM.
> im using several threads to max the speed and im currently cpu bound for
> performance.
> its importent for me to keep the init time as low as possible, since it
> delays failover response in my setup.
> (long time outs on client IO keeps client in an ok state though.)
>
> I have a general interests in performance despite that im using
> webservices for clients =),
> and tend to look around in code on my sparetime, and i sometimes find
> things.
> Whenever the things are not risky to implement, its often to be
> considered free as in beer.
> Its only if there is noticable complexity, that the performance boost
> must be proven to be very substantial inorder
> to motivate risky code changes imo.
>
> I would be happy if its possible to check for isUpdatable in the
> official codebase,
> its a mess for me to keep local patches synced with CVS.
>
> I dont have any hard numbers atm.
> If its needed, i can try to provide it next week or so ?
>
No I don't need the numbers, I was just curious if you had them handy.
Also I was initially looking at the full cost of isUpdateable and the
idea that for a small ResultSet it would be faster to just do the copy
rather than doing the parsing and stuff to see if a ResultSet was
updateable. Re-reading that now, we don't really want to call
isUpdateable, but probably just wrap things in "if (resultsetconcurrency
== ResultSet.CONCUR_UPDATABLE) { } ". That'll be a simple quick check
that should always be a win.
So are you planning on coding this up, or just throwing it out as a
suggestion?
Kris Jurka
