On Sat, May 30, 2009 at 02:41:30AM +0200, Hartmut Henkel wrote:
seems the longer one lets it run in gdb, the more likely one, on a randomly entered ^C, ends up around the while loop within the chunk @
= so maybe it has something to do with the rover and some linked list there.
yes this seems to be the cause. I re-run the test with gprof and got this report: tex: ,-------- | Each sample counts as 0.01 seconds. | % cumulative self self total | time seconds seconds calls s/call s/call name | 37.61 111.05 111.05 90100100 0.00 0.00 ztrybreak | 9.33 138.60 27.55 708325535 0.00 0.00 zgetnode | 8.90 164.88 26.27 1 26.27 294.72 maincontrol | 8.16 188.97 24.09 1253467536 0.00 0.00 zbadness | 5.09 203.99 15.02 4566038 0.00 0.00 zhpack | 4.88 218.39 14.40 4566038 0.00 0.00 hlistout | 3.98 230.15 11.76 100000 0.00 0.00 zlinebreak `-------- pdftex: ,-------- | Each sample counts as 0.01 seconds. | % cumulative self self total | time seconds seconds calls s/call s/call name | 36.99 174.44 174.44 708325535 0.00 0.00 zgetnode | 27.09 302.17 127.73 90100100 0.00 0.00 ztrybreak | 6.30 331.89 29.72 1 29.72 469.55 maincontrol | 5.08 355.83 23.94 1253467536 0.00 0.00 zbadness | 3.29 371.33 15.50 4566038 0.00 0.00 zhpack | 3.28 386.79 15.46 4566038 0.00 0.00 hlistout | 3.09 401.34 14.55 100000 0.00 0.00 zlinebreak `-------- so indeed pdftex seems to spend a lot of time allocating memory. The number of zgetnode() calls is the same (708325535 in both cases), however pdftex calls took more time... Regards, Thanh