Strings

[ktamp]

Strings are past as parameters to procedures by value, which is good but time consuming.

It would be better (faster) if a pointer to the original value was used internally as long as the procedure would not try to change this value, while this pointer would point to the new value if the procedure tried to change it.

This would significantly speed up for example the use of Val?() on data containing millions of strings, while in most cases it would make Len() a real alternative to MemoryStringLength().

It is not pretty to always pass pointers to strings as parameters to procedures for performance reasons, no matter whether you really want to change the contents of these strings or not...

[Fred]

Please note than all PB commands are not affected by string copy, unlike user procedure. Thus Val() and Len() as fast as possible.

[ktamp]

Then I wonder why on my system Len() is 18% slower than MemoryStringLength()...

[Rescator]

Did you compare with Debug on or off? (when compiling/running it from the menu)

[ktamp]

Debug is off and the size of the string is 10^6 bytes.

[Fred]

That's wierd as the 2 functions have exactly the same code. We use another C compiler for the Len() function tough, that could explain that.

[Mistrel]

It's pretty surprising what some compiler optimizations can do. Would the slower compiler happen to be tcc? I also think I read you guys like Pelles C somewhere.