Hi all,
I got some trouble compiling a finite element program called charles.
I used
GNU Pascal version 20020910, based on gcc-2.95.2 19991024 (release).
to compile the program with profiling using the switch -pg. Because the program took an unusual amount of time running, I made a profile. Profiling the run yields that Preparedisposepointer uses exceedingly long times. This is the result for a fairly small problem, used to get output for this mail. I have seen 95% time use for Preparedisposepointer, but lost that profile testing other versions of gpc, and I am not patient enough to regenerate it, now that this output also shows the problem:
/hole 17 % gprof `which charles` | more Flat profile:
Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 59.13 3.14 3.14 Preparedisposepointer 3.20 3.31 0.17 _p_read_longreal 3.20 3.48 0.17 _p_trim ...
(sorry for the crappy lay-out)
Charles, compiled by an older version (see below) of gpc (seems to) works fine, but suffers from a memory leak in the file-io routines.
(older version of gpc) /hole 20 % /usr/tm/bin/gpc --version 2.95.2 19991024 (release)
I was not able to locate the difference in the pascal sources that explains why Preparedisposepointer now needs so much time. However, I suspect FreeMemPtr^ (in rts/heap.pas) does some things. A colleague mentioned that it might be a lot of moving in memory to prevent fragmentation.
I tried to create a test program that creates a linked list of integers and disposes it. Then the allocation and de-allocation times are similar in magnitude:
Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 44.07 1.30 1.30 1 1.30 1.30 pascal_main_program 15.93 1.77 0.47 _p_new 10.85 2.09 0.32 Preparedisposepointer 10.51 2.40 0.31 _p_dispose
Using 8 % gpc --version gpc 20030209, based on gcc-3.2.1 does not change much: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 46.82 1.40 1.40 1 1.40 1.40 pascal_main_program 16.39 1.89 0.49 _p_dispose 13.04 2.28 0.39 _p_new 9.36 2.56 0.28 Preparedisposepointer 6.69 2.76 0.20 Addheaprange
Still allocation and deallocation take similar times
Now I have the following questions: Any idea why deallocation takes forever in the FE program as compared to allocation? Maybe the reason is that the data-structure is slightly more complicated than a linked list of integers ;-) How can I isolate the problem? What kind of feedback can I provide you with to isolate and solve the problem?
Gpc 20030209, based on gcc-3.2.1 does not compile the FE program, but that is another story, which is in my next mail.
Regards, Marten Jan