Re: [lazarus] Who Discussed Linker Slowness?
And there's really no way to accelerate linking - in any way? Maybe (for testing purposes only) just create a library per unit and form and run it from a earlier compiled and already linked application? It is boring to compare to delphi, allways. But there must be different ways to target. If it isn't the delphi fast way there still could be a fpc/lazarus fast way. Is anybody using a way around or are you all day waiting? It's such a waste of time, especially if I try to eliminate a run time error or similar (or maybe I'm just amateur in programming). Greets, Johannes _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
RE: [lazarus] Who Discussed Linker Slowness?
I rebuild Lazarus from the menu and linker seems to be ok now... Is it the correct way to do so ?? -Original Message- From: Johannes Nohl [mailto:[EMAIL PROTECTED] Sent: Monday, February 13, 2006 5:43 PM To: lazarus@miraclec.com Subject: Re: [lazarus] Who Discussed Linker Slowness? And there's really no way to accelerate linking - in any way? Maybe (for testing purposes only) just create a library per unit and form and run it from a earlier compiled and already linked application? It is boring to compare to delphi, allways. But there must be different ways to target. If it isn't the delphi fast way there still could be a fpc/lazarus fast way. Is anybody using a way around or are you all day waiting? It's such a waste of time, especially if I try to eliminate a run time error or similar (or maybe I'm just amateur in programming). Greets, Johannes _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
anthonyb wrote: I rebuild Lazarus from the menu and linker seems to be ok now... Is it the correct way to do so ?? Actually rebuilding just the LCL is good enough. Vincent _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
On 2/13/06, anthonyb [EMAIL PROTECTED] wrote: I rebuild Lazarus from the menu and linker seems to be ok now... Is it the correct way to do so ?? By doing this you will lose the benefits of smartlinking, i.e. executables about 30% smaller. This is a exchange. With smartlinking the executable is smaller, without, the linker is faster. There is a study about this here: http://wiki.lazarus.freepascal.org/index.php/File_size_and_smartlinking -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
RE: [lazarus] Who Discussed Linker Slowness?
Yes but this way, we have every time we build something faster link-time, which is essential because we do it continuously, and when we are done we use strip (and then upx) and we get smaller executables easily... -Original Message- From: Felipe Monteiro de Carvalho [mailto:[EMAIL PROTECTED] Sent: Monday, February 13, 2006 7:30 PM To: lazarus@miraclec.com Subject: Re: [lazarus] Who Discussed Linker Slowness? On 2/13/06, anthonyb [EMAIL PROTECTED] wrote: I rebuild Lazarus from the menu and linker seems to be ok now... Is it the correct way to do so ?? By doing this you will lose the benefits of smartlinking, i.e. executables about 30% smaller. This is a exchange. With smartlinking the executable is smaller, without, the linker is faster. There is a study about this here: http://wiki.lazarus.freepascal.org/index.php/File_size_and_smartlinking -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
On 2/13/06, anthony boudouvas [EMAIL PROTECTED] wrote: Yes but this way, we have every time we build something faster link-time, which is essential because we do it continuously, and when we are done we use strip (and then upx) and we get smaller executables easily... I think you did not understand. After strip and upx, comparing a file with smartlinking and one without smartlinking. The smartlinked executable is 30% smaller. Read the link on my other e-mail. Perhaps the ideal would be if we could have one LCL without smartlinking for the creation process and another with smartlink for the final Release? How big / difficult would this be? -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
RE: [lazarus] Who Discussed Linker Slowness?
I understood what you said but this way, link times are just unacceptable, so the only work around, at least for me, is to strip/upx at the end. Maybe the solution, as many states, is a brand new linker... -Original Message- From: Felipe Monteiro de Carvalho [mailto:[EMAIL PROTECTED] Sent: Monday, February 13, 2006 9:38 PM To: lazarus@miraclec.com Subject: Re: [lazarus] Who Discussed Linker Slowness? On 2/13/06, anthony boudouvas [EMAIL PROTECTED] wrote: Yes but this way, we have every time we build something faster link-time, which is essential because we do it continuously, and when we are done we use strip (and then upx) and we get smaller executables easily... I think you did not understand. After strip and upx, comparing a file with smartlinking and one without smartlinking. The smartlinked executable is 30% smaller. Read the link on my other e-mail. Perhaps the ideal would be if we could have one LCL without smartlinking for the creation process and another with smartlink for the final Release? How big / difficult would this be? -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
On Monday 13 February 2006 17:55, Lord Satan wrote: Is anybody using a way around or are you all day waiting? The way around is running under Linux where linking is much faster. As often said the speed problems are caused by the GNU linker and AFAIK there is no way to solve this other than writing a new linker. I was the one who first pointed this out, and I can give you a few insights, a large part of the speed issue is with the way GNU ld seems to treats (lazarus?) sources and their libraries. Linking speed become a direct factor of how much ram you have. My little 128mb laptop starts swapping like a maniac while linking and can take 30 minutes on anything with more than a few basic widgets, same code on my desktop (2GB of ram) takes about 3 seconds. What I did find is that the best way to up the linker speed when you don´t have a lot of ram is to write a wrapper script in /usr/bin (I called mine nicefpc) which will launch ppc386 with a much lower nice value (I used -18) then give it the suid bit so it can actually be launched and pass ppc386 a $* (so it gets all the parameters) and then tell lazarus to use nicefpc as it´s compile command. This ONLY works under linux but with the nice value way below everything else ppc386 and it´s spawns (like ld) all get maximum priority for memory and CPU access. Just don´t try to read mail while compiling :) Of course this works only under linux, dunno if there is a way to do something similiar on win32. A.J. -- 80% Of a hardware engineer's job is application of the uncertainty principle. 80% of a software engineer's job is pretending this isn't so. A.J. Venter Chief Software Architect OpenLab International http://www.getopenlab.com | +27 82 726 5103 (South Africa) http://www.silentcoder.co.za| +55 118 162 2079 (Brazil) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
Isn't it possible to run a compiled application without linking it together before? For testing a lazarus application it would be enough. If it's possible you could add a Final Build Menu item. Or am I completly out of logic? (I'm not very familliar with internal stuff) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
On 2/12/06, Johannes Nohl [EMAIL PROTECTED] wrote: Isn't it possible to run a compiled application without linking it together before? Linking is the process of putting the compiler pieces together unit a executable file. So no, you cannot run unless you link. -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
you could add a Final Build Menu item. I think, this is an good idea, a publish menue Item can strip and maybe upx the executable. An public folder describes where to place the final executable. Christian _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
Christian U. wrote: you could add a Final Build Menu item. I think, this is an good idea, a publish menue Item can strip and maybe upx the executable. An public folder describes where to place the final executable. And that is exactly what publish project can do, when you have configured it correctly. Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
What do PPU files contain? symbolic links or hard links? See below: - The .TPU format doesn't contain symbolic links to other units, it contains hard links to particular offsets in the interface part of other .TPU files. If those other units change their interface, the .TPU is made obsolete and needs to be recompiled. - Any reasonable update beyond a minor bug fix release is likely to change the interface of some commonly used units like SYSTEM. This makes everything obsolete. - Borland chose to do things this way because it leads to drastic speedups in linking. Essentially all the work involved in linking a unit to the units it uses gets done during compile time, and doesn't need to be repeated again when the program is linked. Quoted from: http://groups.google.com/group/comp.lang.pascal/browse_thread/thread/9cee95654ec4d045 /0d7281be97540061?q=%22windows+was+written+in+pascal%22hl=en _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
On Sun, 15 Jan 2006, L505 wrote: What do PPU files contain? symbolic links or hard links? They don't contain links at all. The accompagnying .o files contain symbolic links, as they are standard elf or pecode object files. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
On Sun, 15 Jan 2006, L505 wrote: What do PPU files contain? symbolic links or hard links? They don't contain links at all. The accompagnying .o files contain symbolic links, as they are standard elf or pecode object files. Michael. Ahh I see.. does microsoft visual studio create similar pecode object files? I'm thinking maybe one reason borland delphi compiler/linker is so fast is because of these hard links - but I'm no compiler guru yet. As for C++ Builder I'm not sure, I've heard it was slow compiler/linker. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
At 09:26 15-1-2006, you wrote: What do PPU files contain? symbolic links or hard links? See below: - The .TPU format doesn't contain symbolic links to other units, it contains hard links to particular offsets in the interface part of other .TPU files. If those other units change their interface, the .TPU is made obsolete and needs to be recompiled. - Any reasonable update beyond a minor bug fix release is likely to change the interface of some commonly used units like SYSTEM. This makes everything obsolete. - Borland chose to do things this way because it leads to drastic speedups in linking. Essentially all the work involved in linking a unit to the units it uses gets done during compile time, and doesn't need to be repeated again when the program is linked. PPU contains hard-links to symbol numbers. See the output of ppudump. But PPU information is only used for compilation. For the linker standard .o files are generated. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
At 20:16 15-1-2006, you wrote: On Sun, 15 Jan 2006, L505 wrote: What do PPU files contain? symbolic links or hard links? They don't contain links at all. The accompagnying .o files contain symbolic links, as they are standard elf or pecode object files. Michael. Ahh I see.. does microsoft visual studio create similar pecode object files? I'm thinking maybe one reason borland delphi compiler/linker is so fast is because of these hard links - but I'm no compiler guru yet. As for C++ Builder I'm not sure, I've heard it was slow compiler/linker. Yes, delphi and tp7 are fast because it has an internal linker and the dcu/tpu files contain everything needed to do incremental linking. FPC is slower because it needs to write PPUs for its own and write .o files for the linker. Then the linker is called as external program requiring also program startup and it needs to read the .o file. So in short: The only way to get a major speedup in linking is to have an internal linker so the .o is not needed anymore and can be stored in the ppu. But i don't have the time to code such an internal linker so don't expect anything before 2007. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
So in short: The only way to get a major speedup in linking is to have an internal linker so the .o is not needed anymore and can be stored in the ppu. But i don't have the time to code such an internal linker so don't expect anything before 2007. And I wonder about the Windows.a and Windows.o file, do you think borland uses some magic tricks there or do they actually just treat the windows.tpu/windows.dcu file just like any other dcu file. I guess I will look at the DCU file and report back with more information, but it is hard to say whether they place the entire dcu file into memory or whether they have some other magic tricks up their sleeves. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
At 20:40 15-1-2006, you wrote: So in short: The only way to get a major speedup in linking is to have an internal linker so the .o is not needed anymore and can be stored in the ppu. But i don't have the time to code such an internal linker so don't expect anything before 2007. And I wonder about the Windows.a and Windows.o file, do you think borland uses some magic tricks there or do they actually just treat the windows.tpu/windows.dcu file just like any other dcu file. I guess I will look at the DCU file and report back with more information, but it is hard to say whether they place the entire dcu file into memory or whether they have some other magic tricks up their sleeves. All those external references to DLLs are generated by the linker and don't need to be stored in the dcu. For FPC we can do the same since ld now also supports direct linking to DLL files. When the FPC port to win32 started that was not the case. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
All those external references to DLLs are generated by the linker and don't need to be stored in the dcu. For FPC we can do the same since ld now also supports direct linking to DLL files. When the FPC port to win32 started that was not the case. I remember that was discussed in the article you pointed out, thanks for clearing this up. I wonder how much this will improve speed, I think the article said 10-25 percent. Only experimenting will tell I guess :-) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
At 22:29 15-1-2006, you wrote: All those external references to DLLs are generated by the linker and don't need to be stored in the dcu. For FPC we can do the same since ld now also supports direct linking to DLL files. When the FPC port to win32 started that was not the case. I remember that was discussed in the article you pointed out, thanks for clearing this up. I wonder how much this will improve speed, I think the article said 10-25 percent. Only experimenting will tell I guess :-) You can expiriment yourself, use the 2.1.1 compiler from today and compile everything with option -WI-. Peter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
You can expiriment yourself, use the 2.1.1 compiler from today and compile everything with option -WI-. Oh! Send -WI- to the compiler? or the linker with -k ? Lars _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
Florian Klaempfl wrote: Units imported from dlls require import entries. This would increse the size of executables significantly Yes, was afraid of that. We would need to make a wincommon or so, with all those that LCL uses (or any other measure of common), winextra, win2k, winxp, etc, Hmmm... Micha _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
Florian Klaempfl wrote: Units imported from dlls require import entries. This would increse the size of executables significantly Yes, was afraid of that. We would need to make a wincommon or so, with all those that LCL uses (or any other measure of common), winextra, win2k, winxp, etc, Hmmm... Some interesting stuff about ld can be found at http://sourceware.org/binutils/docs-2.16/ld/WIN32.html under direct linking to a dll _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
An extra handicap for the linker is the fact that the windows unit, which is rather large is always smartlinked, resulting in (I estimate) ten thouands of object files (archived in the .a file). You probably won't have this amount of .o files in c programs. Vincent. Windows.ppu is about 1.692 MB in size, quite a big .ppu file libwindows.a is about 3.451 MB in size, quite a big .a file what do C programs use for the windows API interface? Isn't it a huge C header file that gets put into a .a/.o file? _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
L505 wrote: Of course it is probably the Win32 linker that is the real slow one, and I don't know why that is - so any mailing lists threads or sites you know of please post them here and/or discuss. An extra handicap for the linker is the fact that the windows unit, which is rather large is always smartlinked, resulting in (I estimate) ten thouands of object files (archived in the .a file). You probably won't have this amount of .o files in c programs. Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
Of course it is probably the Win32 linker that is the real slow one, and I don't know why that is - so any mailing lists threads or sites you know of please post them here and/or discuss. I guess part of the slowness is the use of GROUP() and the large libpwindows.a _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
Vincent Snijders wrote: An extra handicap for the linker is the fact that the windows unit, which is rather large is always smartlinked, resulting in (I estimate) ten thouands of object files (archived in the .a file). You probably won't have this amount of .o files in c programs. Can we seperate the windows unit in a unit that has function declarations that all versions of windows have, and one that only WinNT/2k/others have? Or is this not practical ? Micha _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
Micha Nelissen wrote: Vincent Snijders wrote: An extra handicap for the linker is the fact that the windows unit, which is rather large is always smartlinked, resulting in (I estimate) ten thouands of object files (archived in the .a file). You probably won't have this amount of .o files in c programs. Can we seperate the windows unit in a unit that has function declarations that all versions of windows have, and one that only WinNT/2k/others have? Or is this not practical ? Units imported from dlls require import entries. This would increse the size of executables significantly _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Who Discussed Linker Slowness?
Vincent Snijders wrote: An extra handicap for the linker is the fact that the windows unit, which is rather large is always smartlinked, resulting in (I estimate) ten thouands of object files (archived in the .a file). You probably won't have this amount of .o files in c programs. Can we seperate the windows unit in a unit that has function declarations that all versions of windows have, and one that only WinNT/2k/others have? Or is this not practical ? You'll get an executable that has a lot of DLL dependencies. And that is therefor also a lot larger. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
