FPC 3.1.1. vs 2.6.4

[Jonas Maebe]

I think the main slowdown comes from the fact that the RTL now is correctly aware of the fact that on Windows the ansi codepage (i.e., the codepage of default ansistrings and shortstrings, aka CP_ACP) is different from the console codepage (the code page that must be used by writeln, aka CP_OEM). As a result, on Windows every single write(ln) of any string is going to result in a code page conversion with new FPC versions, while with old FPC versions that was not the case (which probably also meant that some characters could be output wrongly).

Note that when I wrote the above, I hadn't looked at the program's source code and thought it was writing to the console. Since it's writing to a file, the above is not applicable (by default, the output to the file will be in the ansi code page as well, so no code page conversions will occur).

Is there an option to change that?

E.g. if you want to output UTF-8, if the output is redirected to a file

I don't think the RTL exports a routine to query whether or not the output is redirected. Getting/setting the encoding of any textfile (including input, output and stderr) can be done via system.GetTextCodePage(text):TSystemCodePage and system.SetTextCodePage(text,TSystemCodePage) though.

[zeljko]

Last night I've installed trunk fpc + trunk lazarus via script from getlazarus.org and then build my erp application, and was pretty impressed release binary size is reduced cca 20% in compare to 2.6.4. Both are compiled with -Mdelphi -O2 and then stripped. Fedora 19 32bit. Nice

[airpas]

also when you build lazarus with "optimized ide" profile  , this will reduce the exe size .
on linux with optimized ide profile an empty window is only 1.8mb , with normal profile the size is ~4mb

[Leledumbo]

on linux with optimized ide profile an empty window is only 1.8mb , with normal profile the size is ~4mb

To be precise:

• i386-linux-qt = 1,617,100 bytes ~= 1,5 MB
• i386-linux-gtk2 = 1,886,124 bytes ~= 1,8 MB
• x86_64-linux-qt = 2,122,584 bytes ~= 2,0 MB
• x86_64-linux-gtk2 = 2,492,256 bytes ~= 2,4 MB

[BeniBela]

I don't think the RTL exports a routine to query whether or not the output is redirected. Getting/setting the encoding of any textfile (including input, output and stderr) can be done via system.GetTextCodePage(text):TSystemCodePage and system.SetTextCodePage(text,TSystemCodePage) though.

That is quite an unreliable function

Code: [Select]




-----------Windows--|---Linux default---|--Linux cwstrings
CP_ACP   |   ok     |        ok         |        ok
         |          |                   |
1252     |   ok     |       FAILS       |        ok
         |          |                   |
CP_UTF16 |  FAILS   |       FAILS       |        ok
         |          |                   |
CP_UTF32 |  FAILS   |       FAILS       |        ok
(12000)


[Jonas Maebe]

The "Linux default" case is irrelevant: no codepage conversion can work with that, also with previous FPC versions.

Please file bug reports for the failing Windows cases, along with an example that demonstrates the problem (for example, it is important to know whether you are testing this with writing to a text file, or to the console -- in the latter case, on Windows you probably also have to configure your cmd windows in a way that supports arbitrary unicode codepoints, because afaik by default it only supports the OEM codepage charset).

[Jonas Maebe]

Additionally, do you mean that it works/doesn't work when you write UTF16/UTF32 strings to the text file, or that it works/doesn't work when you configure the text file itself for UTF16/UTF32? The latter is completely unsupported on any platform (if it works on Linux, that's purely coincidence). Unfortunately, the SetTextCodePage() function is modelled on Delphi's API and has no way to report errors to the caller (other than possibly triggering a run time error).

[BeniBela]

r that it works/doesn't work when you configure the text file itself for UTF16/UTF32? The latter is completely unsupported on any platform (if it works on Linux, that's purely coincidence).

This

It would make it much simpler to create a file in any encoding

[BeniBela]

I think the main slowdown comes from the fact that the RTL now is correctly aware of the fact that on Windows the ansi codepage (i.e., the codepage of default ansistrings and shortstrings, aka CP_ACP) is different from the console codepage (the code page that must be used by writeln, aka CP_OEM). As a result, on Windows every single write(ln) of any string is going to result in a code page conversion with new FPC versions, while with old FPC versions that was not the case (which probably also meant that some characters could be output wrongly).

And readln, too!

Another trap to consider.

Call otherprogram | fpcprogram  and fpc assumes otherprogram outputs  the console codepage and wants to convert it. There rarely is a need to convert anything

[Thaddy]

If you use shortstrings you'll get fast code. Has always been the case. Shortstrings have also been always limited compared to the later string types.
In actual fact the current compiler generates much faster code then all the previous compilers. In effect, that makes the new features acceptible to me.
As is the case with many languages and frameworks. Also note that code that does not rely on the advanced string manager is just as fast as ever.
Moaning about the speed of new features is not warranted if you did not know you can revert back to the old behavior and in this case the new features aren't even enabled by default.
You have to install a string manager.