[fpc-devel] dominant short strings in compiler source

[L505]

> > The SysUtils unit misses some performance tweaks that the Dos unit has.
> > Especially for the FindFirst/FindNext part. But this has low prio for the
> > current developpers so it hasn't been analysed and fixed yet.

What do you guys thing about the idea to implement what DEC Pascal and Extended Pascal
have - a 2 byte length ShortString (MediumString?), uprdade *some* of the path related
ShortStrings to be MediumString[1000] instead of ShortString[255]. For some situations
it would probably fix some problems immediately just by upgrading to string[1000] or
even string[500].

I wondered why Borland/FPC didnt' implement a 2 byte length storage short string in
addition to the 1 byte length storage short string.. maybe just haven't gotten around
to it? Maybe there are other reasons? I think it is a good idea to have a really short
string which has a maximum element count of 255, and to also have another larger
shortstring which can go past 500 if you want it to. You'd rarely use 60,000 you'd
mainly use figures within the 255-2000 range.

This would keep speed up without affecting way we think much - they are still short 
strings, just longer ones. You'd still have the option of using a 255 shortstring. 
Many changes would be needed if you turned items into an ansistring or a list of 
small 255 strings - but if all you had to do was upgrade the string to string[1000] 
it may serve the compiler well for 10 years until people start having hard drives 
with REALLY long paths that combine to exceed 1000 - then maybe you upgrade to 
1500, or start separating the strings into a list of strings.