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
