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
