The forum for ZeosLib 7.2 Report problems. Ask for help, post proposals for the new version and Zeoslib 7.2 features here. This is a forum that will be edited once the 7.2.x version goes into RC/stable!!
My personal intention for 7.2 is to speed up the internals as optimal a possible for all IDE's. Hope you can help?! Have fun with testing 7.2
does someone knows a IntToStr/StrToInt replacement for the Unicode IDE's which NOT returns/uses a UnicodeString? Casting/Converting the UnicodeString down to single byte strings eats time.
function IntToRaw(I: Integer): RawbyteString;
begin
{$IFDEF UNICODE}
Str(I: 1, Result); //In average 300ms faster of exec count 10.000.000x instead of casting or using ASCII7 function to get a RawByteString
{$ELSE}
Result := IntToStr(i); //In average 10ms slower of exec count 10.000.000x instead of direct calling IntToStr
{$ENDIF}
end;
function IntToRaw(I: Int64): RawByteString;
begin
{$IFDEF UNICODE}
Str(I: 1, Result); //In average 100ms faster of exec count 10.000.000x instead of casting or using ASCII7 function to get a RawByteString
{$ELSE}
Result := IntToStr(i); //In average 10ms slower of exec count 10.000.000x instead of direct calling IntToStr
{$ENDIF}
end;
So it would be nice to have faster funtions which do return/work with rawbytestrings direcly and NO speed decrease happens for the Ansi-IDE's..
uhhh oooh, YES that's what i want to see. I remember Delphi(since D2007) uses some code of John O'Harrold, etc. nowadays too. No copyrights.. Well done, Michal! I'll benchmark these functs tonight and add them!
Remaining is StrToInt with in Param SingleByteString (RBS). The casts we need to support the newer UnicodeIDE's slowing down a loads of processes. Any ideas?
added pure pascal code of John O'Harrow:
10x faster than Delphi or FPC RTL for 32Bit Integer
2x faster than Delphi or FPC RTL for 64Bit Integer
the assambler code written by John O'Harrow i currently not use (did test a lot but have some remaining issue with the UnicodeIDE's and setting a CopdePage to the Strings). Also do i need some defines because asm is less portable.
the UnicodeIDE's have inparam s: String (UnicodeString) (even if they cast the type down)and i cant access __vallong, __valext of the system unites..
the only base primitive they left was Str().
Inbetween i wrote a set of functions which work with Wide/Unicode-Strings and RawByte/AnsiStrings to avoid each typecast.
Check ZSysUtils.pas use them for FPC if you want, Marco. If you ever plan going Unicode than please do it better than Delphi. (:
We'll probably be exactly the same, with an overload extra here and there. We are studying on the ability to compile something Delphi-old and delphi-unicode from the same source, but the delphi-old stuff will be legacy (and probably die out in time)
There was some movement recently, system and sysutils file/dir functions have been updated to unicodestring in a branch, and it is also possible to compile unit Windows in two-byte mode.
Probably the classes level will be next (to convert to two byte mode) in fall.
Well i know the most should be equal. For me it's annoying that Delphi didn't left base functions to use single-byte encoded strings.
FloatToStr, IntToStr, FormatDateTime f.e. where you can't use overloads. So i wrote some two way directions like IntToUnicode, IntToRaw etc.
And raw overloads for StrToInt or StrToFloat do not exist too. i know Delphi Ansi will die out in time but there is still a loads of such base fundamential required working with single-byte based RDBM's.
It really would be nice (mostly for others, because Zeos have it's own routines inbetween) to have some functions to work in two way directions. Also is the Stream-Thing of Delphi a terrible stupid thing. TStringList.SaveToStream still writes single-byte streams.. Encoding? Data-Loss?
Just some Dev hints:
FPC Variant doesn't support the RawByteString assignments.
SetString for UTF8String and RawByteString isn't supported for FPC2.7 too..
