Recent

Author Topic: Free Pascal takes about minute to compile a helloworld (64-bit Debian Stretch)  (Read 6697 times)

geek893

  • New Member
  • *
  • Posts: 24
OS: 64-bit Debian Stretch. When I was on 32-bit Debian Jessie there wasn't such problem, compilation was fast. The hardware is the same as before. The same goes for compilation command. Compilation command: fpc filename.pas -g -Cr. My systems is mixed, it allow execution and installation of both 32-bit and 64-bit applications. It seems that 99% of time takes linking. It seems that other languages (like C) aren't affected by such problem. Compilation of *.lpr files in Lazarus works fine.

This code took 52 second to compile:

Code: Pascal  [Select][+][-]
  1. BEGIN
  2. write('Hello, cruel world!');
  3. END.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
If you compile with -vas, the compiler will show everything it does and prefix every message with a timestamp. That should allow you to get a better idea about what is taking so long.

Thaddy

  • Hero Member
  • *****
  • Posts: 14198
  • Probably until I exterminate Putin.
OS: 64-bit Debian Stretch. When I was on 32-bit Debian Jessie there wasn't such problem, compilation was fast. The hardware is the same as before. The same goes for compilation command. Compilation command: fpc filename.pas -g -Cr. My systems is mixed, it allow execution and installation of both 32-bit and 64-bit applications. It seems that 99% of time takes linking. It seems that other languages (like C) aren't affected by such problem. Compilation of *.lpr files in Lazarus works fine.

This code took 52 second to compile:

Code: Pascal  [Select][+][-]
  1. BEGIN
  2. write('Hello, cruel world!');
  3. END.
You must have something criminally wrong because it compiles on a humble RPi in less than  0.1
Specialize a type, not a var.

geek893

  • New Member
  • *
  • Posts: 24
Quote
That should allow you to get a better idea about what is taking so long.
Thanks for the idea. Does it work by principle "do a thing and only then report that you did it?". If yes, then it's all fault of "[0.156] Linking helloworld" step. Everything else works momentally.  Although I said already that it's linking that slows everything down.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
The compiler usually first writes what it is going to do and only then does it. To really be sure it's the linking step, you could compile with -Cn and then execute the generated ppas.sh. That shell script will then just execute the linking step.

If that's the issue, please report a bug against binutils at https://sourceware.org/bugzilla/ (compile with -Cn, and include all FPC-related files referenced from the generated ppas.sh and link.res)

Nitorami

  • Sr. Member
  • ****
  • Posts: 481
I am having the same issue on my office PC, windows 7, textmode IDE 3.0.4, a hello world program taking 5 seconds for linking. The issue only appeared a few months ago, and I am fairly certain it is related to the virus scanner running in the background. I tried to exclude all relevant directories from the scan, but no avail, this is a realtime scanner which seems to hook into running processes, and I cannot stop it without admin rights.

The linking stage takes 5 seconds, then another 5 seconds before the compiled program starts running. Nevermind, the problem goes away when the IDE has run for 15 minutes or so in the background. Seems that by then the scanner has convinced itself there is no harm... therefore I try to keep the IDE running in the background all the time; whenever I terminate and restart it, the issue is back - for the next 15 minutes.
No such issues on my home PC.

geek893

  • New Member
  • *
  • Posts: 24
The compiler usually first writes what it is going to do and only then does it. To really be sure it's the linking step, you could compile with -Cn and then execute the generated ppas.sh. That shell script will then just execute the linking step.

According to "time" execution of ppas.sh took about 3 seconds. Probably much slower than it should be for helloworld, but it's clearly isn't reason of the main slowdown.

When I compiled with -Cn I also used -va for detailed log. It seems that primary candidates for bottleneck are "[41.254] Searching file /usr/bin/ld... found" and
"[41.254] Using util /usr/bin/ld"

Quote
I am having the same issue on my office PC, windows 7, textmode IDE 3.0.4, a hello world program taking 5 seconds for linking. The issue only appeared a few months ago, and I am fairly certain it is related to the virus scanner
Firstly, this is called an antivirus monitor, not an antivirus scanner. Secondly I don't use antivirus monitor because I use Debian Linux.


Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
According to "time" execution of ppas.sh took about 3 seconds. Probably much slower than it should be for helloworld, but it's clearly isn't reason of the main slowdown.
Indeed.

Quote
When I compiled with -Cn I also used -va for detailed log. It seems that primary candidates for bottleneck are "[41.254] Searching file /usr/bin/ld... found" and
"[41.254] Using util /usr/bin/ld"
Not sure. This means that searching for /usr/bin/ld took less than 0.001 seconds. The primary candidate for the bottleneck would be before that.

Another thing you could try is compile with -Fd. This disables the compiler's internal directory cache. By default, whenever the compiler searches for a file in any directory, it caches the names of all files in that directory so future searches can be done without going to disk. This is because the compiler often needs to look for multiple files in the same directory (multiple extensions, different case, different units/include files). This caching of directories should not take tens of seconds even if they contain a ton of files, but it's another thing you can try to rule out.

Also, did you switch to a different type of file system when going from 32 to 64 bit?
« Last Edit: June 30, 2018, 01:41:10 pm by Jonas Maebe »

geek893

  • New Member
  • *
  • Posts: 24
It seems like I found the reason for slowdown. The partition was mounted with "sync" flag. I removed this flag from /etc/fstab and now compilation is fast.

Quote
Also, did you switch to a different type of file system when going from 32 to 64 bit?
Nope.

 

TinyPortal © 2005-2018