Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
2) Nothing is copied on an assignment to a string variable, except the reference to the memory object. Sorry, I erroneously thought about the variable itself being ref counted, while in fact the variable is a pointer to the (hidden) String management record, which is the ref counted entity

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Van Canneyt
On Thu, 27 Jun 2013, Michael Schnell wrote: 2) Nothing is copied on an assignment to a string variable, except the reference to the memory object. Sorry, I erroneously thought about the variable itself being ref counted, while in fact the variable is a pointer to the (hidden) String

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/27/2013 09:51 AM, Michael Van Canneyt wrote: There is no content pointer. The string array is appended to the record I see. Thus the pointer is relative and implicate :-P . Silly me. -Michael ___ fpc-devel maillist -

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/26/2013 05:09 PM, Marco van de Voort wrote: Should is a complex thing here, since there is no implementation to test with (and see if it has other consequences). I assume a conversion should be inserted, so at least for non rawbytestrings the runtime encoding always matches the

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Marco van de Voort
In our previous episode, Michael Schnell said: Should is a complex thing here, since there is no implementation to test with (and see if it has other consequences). I assume a conversion should be inserted, so at least for non rawbytestrings the runtime encoding always matches the

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/26/2013 06:29 PM, Hans-Peter Diettrich wrote: Then you have two choices: 1) convert the string as required 2) copy the content unconverted, but update the encoding What do you mean by you have two choices ? In fact the compiler designer has the choice to implement some behavior: 1)

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/27/2013 12:26 PM, Marco van de Voort wrote: That already has been decided, everything Delphi compatible. I was just speaking hypothetic case. The starting point of the discussion was the possibility to improve the compiler/library and potentially introduce mode settings that introduce

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/26/2013 08:01 PM, Sven Barth wrote: The RTL already uses RawByteString for the concatenation helpers. Does this code do an assignment of RawByteString to normal String with not already matching Types (and thus create erroneous Strings) ? I would not suppose so. Otherwise it would be

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/26/2013 10:28 PM, Hans-Peter Diettrich wrote: Please note that I invited Michael Schnell to provide his version of such RTL routines, compatible with *his* ideas about better string handling. I would be happy to do this, but unfortunately the modified behavior would need to be

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Sven Barth
Am 27.06.2013 13:12, schrieb Michael Schnell: A prominent example is TStringList. I have no idea how it is implemented in DXE, but using decent RawByteStrings it can be implemented in a way that can be used with all strings without a severe performance hit. Delphi uses String as type for the

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/26/2013 06:19 PM, Hans-Peter Diettrich wrote: A string variable has no encoding type stored. Only non-empty strings have an encoding. Sorry for bad wording. Not the String variable itself (as same is just a pointer to the String Record) but the string Record it points to has the

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/27/2013 01:24 PM, Sven Barth wrote: Delphi uses String as type for the TStringList and thus with Delphi 2009 and newer this is UnicodeString. I did assume this. As I don't have a new Delphi I in turn don't know what exactly UnicodeString means. From what I read I assume this means

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Marco van de Voort
In our previous episode, Michael Schnell said: As I don't have a new Delphi I in turn don't know what exactly UnicodeString means. utf16 as has been said hundreds of times, and can be seen in thousands of locations on the web. If you don't get these essential features, then all this discussion

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/27/2013 01:48 PM, Marco van de Voort wrote: when storing a - say UTF-8 - String in a stringlist and retrieving it later to a String variable with encoding type UTF-8 a dual conversion is done. Yes. To me this seems absolutely silly. Correct. Using UTF8 on Windows is silly, as it is

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Hans-Peter Diettrich
Michael Schnell schrieb: 2) Nothing is copied on an assignment to a string variable, except the reference to the memory object. Sorry, I erroneously thought about the variable itself being ref counted, while in fact the variable is a pointer to the (hidden) String management record,

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/27/2013 12:54 PM, Hans-Peter Diettrich wrote: Now you also should understand that a string variable points directly to the string content, it's usable as PChar(str) without any conversion. The other information about the string resides *before* that address. I did do the testing

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Marco van de Voort
In our previous episode, Michael Schnell said: Yep. But fpc is not windows-centric, These are all discussion that have raged for years, and an implementation was made. Basta. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/27/2013 02:52 PM, Marco van de Voort wrote: These are all discussion that have raged for years, and an implementation was made. Basta. As I can't do any patch for the compiler myself, I can't comment on that. -Michael ___ fpc-devel maillist -

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Sven Barth
Am 27.06.2013 13:37 schrieb Michael Schnell mschn...@lumino.de: As I don't have a new Delphi I in turn don't know what exactly UnicodeString means. But you do remember that I sent you a list of string types a few days ago? Regards, Sven ___ fpc-devel

Re: [fpc-devel] Performance of string handling in trunk

2013-06-27 Thread Michael Schnell
On 06/27/2013 05:22 PM, Sven Barth wrote: But you do remember that I sent you a list of string types a few days ago? I just wanted to avoid to state something that might be wrong :-[ -Michael ___ fpc-devel maillist -