On Tue, 10 Nov 2009, Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More checks
Where? A pure unicodestring routine won't get additional checks.
and more complicated address calculation.
Where? Adding 16 instead of 12 makes no difference.
The "major" difference will be the initialization of the additional
fields and the increased memory requirement of 4 bytes per string.
OK, you can say "you
will not notice the small difference". But possible this attitude is one of
the reasons that Delphi compiles much faster than FPC? ;-)
Yes, and if compilation speed is important for you, you should use
delphi ;) What you call "this attitude" is also the reason why FPC can
exist: we need always to find a compromise between:
- satisfy the needs of as much as possible users
- maintainability
- portability
- performance
Especially portability is what makes the difference.
It is all about available time.
If we only had to support one target processor and one OS, we could
spend *much* more time on optimisation of the generated code.
But as it is, we have to divide our attention between i386, X86_64,
powerPC (32/64 bit), sparc and ARM. That's 6 CPUs and at least as much
operating systems.
Given the time limits, the first thing to go out of the window is therefor
speed.
MSE boasts some 'great features'. Well, last time I checked
(admittedly some time ago), MSE didn't even support 64-bits,
while Lazarus does since many years.
What to spend time on is a decision each makes for himself:
Martin chose features over platforms. We choose platforms over optimization...
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
