[m-dev.] pprint performance

[Ralph Becket]

Kevin Glynn, Saturday, 23 February 2002:
> 
> Ralph Becket writes:
>  > 
>  > A reasonable solution is probably to use some form of lazy evaluation,
>  > whereby the term conversion is done on-demand by the write procedure.
>  > This should improve matters on those back-ends that support the
>  > extras/lazy_evaluation/lazy.m module (currently the C backends), but
>  > may cause problems for back ends that don't.
>  > 
>  > I'll do some experiments and report back.
> 
> And as soon as I leave you get a clue .... :-)

Nice try, but no cigar.

I've just conducted an experiment whereby every Nth ply of the term
(viewing terms as trees) is formatted on demand by the write procedure.
This occurs in three places:
1. when outputting an as yet unformatted part of a term;
2. when deciding whether to try to fit a group doc that contains an as
yet unformatted part on a single line; and
3. when outputting an as yet unformatted part of a term.

My current implementation does not overwrite the "thunk"s with their
value after evaluation.  It seems to me that to do so would not solve
the problem: the extra memory consumed may still be live after printing,
which is the problem we're trying to solve.

By recomputing each time we do not take up memory.

So much for theory: this method does use considerably less memory, but
it takes between 2.5-3 times longer to print terms (I've tested this
with balanced binary trees containing up to 1 million nodes.)

On ceres it takes 200+s to write such a tree with N = 1, 2 or 4, but
the program still ends up paging (right now I do not understand why.)

More investigation to follow.  In particular, I want to see how well
it performs on MLDS dumps (before it was taking an hour in some
cases...)

> Hope you aren't being driven completely batty by your mother.  (We
> were,  and mine stayed *5* weeks!)

I needed a hefty dose of beer therapy after just one week.  Coming half
way round the globe means I've traded frequency for duration of stay -
God help me!

- Ralph
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------