[fpc-pascal] msedb and fcl-db benchmarks
fpmse at bluewin.ch
Tue Jul 17 09:40:33 CEST 2007
On Monday 16 July 2007 14.20, Joost van der Sluis wrote:
> Hi all,
> To see what the differences in speed are between MSEdb and fcl-db I did
> some benchmarks. (See the attachment for the code and results)
> I tried to explain the readdata-difference. At first I thought that
> msedb converted all strings from string to widestring to string. But it
> doesn't do that. (see my mails on this subject)
You are wrong here.
function tmsebufdataset.loadbuffer(var buffer: recheaderty): tgetresult;
if field1.datatype in charfields then begin
int2:= int2*4+4; //room for multibyte encodings
if not loadfield(field1,pointer(str1),int2) then begin
if int2 < 0 then begin //buffer to small
po2:= pointer(@buffer) + offset;
if bs_utf8 in fbstate then begin
po2^:= utf8tostring(str1); <<<<<<<<<<<<<<<<----
po2^:= msestring(str1); <<<<<<<<<<<<<<<<----
function utf8tostring(const value: utf8string): msestring; overload;
msestring = widestring.
> I think that the only reasonable explanation is the argument from
> Michael: using ansistrings/pointers to store the data instead of storing
> them directly into a buffer, induces so much overhead that it becomes
> too slow.
> Overall, I would conclude that the current design of the TBufDataset of
> fcl-db is a better choice then the design of tmseBufDataset. Since fcl-
> db is faster on those things a TBufDataset is build/meant for: browsing
> through records.
tmsebufdataset is designed to work well with the MSEgui visual components
where TBufDataset was not ideally suited.
> Discussion: What tests could I do more? Is there something I overlooked?
To work with tmsqlquery you should use tmsestringfield.asmsestring and not
TField.AsString, otherwise the slow ansistring<->widestring conversion takes
place on every access. On Windows you should not use FPC 2.1.4+ because
widestrings are no more reference counted and heap based...
More information about the fpc-pascal