Paul Davidson wrote:
Several months ago someone on this list mentioned that GPC was slower than other Pascal compilers.
Would like to comment on one possible cause for this. Please keep in mind than am not familiar with GPC internals. (i.e. Ignorance has never stopped opinions in the past:)
One possible cause for this lack of speed may be due to string handling. The schema used for strings has an allocated length (max allowed) but does not seem to have an actual length.
Yes, it does. (It does not use or need a #0 terminator, except when dealing with "CStrings".)
Another trick that could improve string performance is reference counting.
This is a planned feature for a new kind of strings. It could reduce overhead in cases where strings are mostly copied around. But as you say, this will require quite some work in the runtime and probably even more in the compiler. (For now, there are more urgent things to do.)
Waldek Hebisch wrote:
I think you missed the main point: GPC generates very fast code. So GPC compiled program run fast.
To be fair, it may be somewhat slower when dealing a lot with strings (especially compared to hand-optimized C/assembler code ...). This also depends on the Pascal code -- e.g., using `const' string parameters are a lot faster than value parameters when the actual parameter is a string variable.
I'm not completely sure if there are cases left where GPC copies the capacity (allocated length) instead of the length. This could be a major slowdown if the length is much shorter than the capacity. I tried to eliminate such cases, but if you find them, let me know. (This can be observed from Pascal code by testing the runtime difference when using strings of the same capacity and vastly different length.)
Frank