On 03/07/14 15:14, Dimitry Sibiryakov wrote:
> 07.03.2014 11:53, Alex Peshkoff wrote:
>
>> Main reason is performance compromise. It's faster to store required
>> information from IMessageMetadata somewhere in end-user code and use it
>> to access data instead of calling dozens of virtual functions.
>     There is no difference if you store offset got from a virtual function or 
> a pointer got
> from other virtual function. In any case you'll have to perform 
> "buffer+offset" operation
> every time you use the same or different buffer. With pointer you can receive 
> new pointer
> only if buffer is changed. No difference between 
> "buffer+Metadata.getOffset(i)" and
> "Buffer.getData(i)" which has the same "buffer+Metadata.getOffset(i)" inside.

Certainly, such interface specially oriented on a case when buffer is 
not changed may exist.
But offset-oriented interface is required anyway: remember, we get it 
from server having no buffer at all.
I.e. it will be duplication, which is not good in low level API.

>     Calling of virtual function is cheaper than copying of kilobytes of data.

Yes, but how is it related here?

>> Currently one
>> can just pass single pointer to next buffer to fetch() - and this job is
>> done. Access to fields is usually performed by other layer of component.
>> I have no idea how can IBuffer performing offset-to-pointer conversions
>> help here.
>     Exactly the same way: one just pass next (descendant of) IBuffer to 
> fetch() and there
> is no need to worry how this IBuffer keeps information internally. Default 
> TPlainBuffer
> can keep all values in single piece of memory, someone can invent 
> TScatteredBuffer for any
> reason and so on. Polymorphism will allow server code to work with all of 
> them.

No. To make server work message's buffer should always be plain. 
Certainly, we may rework server code and learn it to work with non-plain 
buffers, but I see no reason to do it.

>> Not sure it's possible for SQLDA where memory for fields allocated by
>> user.
>     It is. If you have in engine a piece of code that looks like this: "p =
> Buffer.getData(i)", then in plain buffer object getData() can be implemented 
> as "return
> buffer+Metadata.getOffset(i)" while in SQLDA-based buffer if will be "return
> sqlda->sqlvars[i].sqldata". No difference for calling code, no need in 
> gathering data from
> user buffers into internal one.

This requires exactly same thing - learn server to work with non-plain 
message buffer.
Doubt this makes server code faster and cleaner.


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to