[NTG-pdftex] processing speed

[The Thanh Han]

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
> @<Try to allocate...@>=
> 
> 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