[m-rev.] for review: arrays and the debugger

[Zoltan Somogyi]

On 18-Jun-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> The new facility proposed looks ugly to me, because it violates the
> principle of keeping the interface simple and providing just the
> basic building blocks, together with powerful ways of combining them,
> rather than trying to provide every individual combination of features.
> 
> The proposed justification for the new facility is efficiency.
> 
> What influences my thinking here is the desire to avoid the evils of
> premature optimization.  Complicating the interface and implementation
> with an extra procedure in order to speed up pretty-printing by 2% or
> even 10% would not be a good trade-off, IMHO.  And so far I haven't seen
> any convincing evidence that the speed up would be that great.

The reason why I *started* working on this is because of my experience with
debugging the deep profiler, which has arrays with several hundred thousand
elements. Doing a "print *" would take ages and fill up your xterm's entire
record many times over. After I modified deconstruct to return array elements
instead of ignoring them, the problem because that the test whether the array
was too big to print took a minute or so, because the allocation of a typeinfo
for each element caused by laptop to swap. This is not a 2% or 10% issue; this
is a feasible vs non-feasible kind of efficiency issue.

If we leave the interface as it is, then even if we document the problem and
suggest your workaround, people will continue to use deconstruct even if their
code some day may be given big arrays as input, because they don't want to slow
down the common case. And they are right. Why should they have to complicate
their code and slow down the common case to handle a rarely occurring but
important problem, when a solution exists that does not require that
compromise?

> Both solutions are equally expressive.  I'm arguing for favouring
> simplicity over unmeasured and probably unimportant performance gains.

And I am saying that the gain is not unimportant.

"Everything should be as simple as possible, but no simpler." I am telling you
that if deconstruct returns array elements, then not having a limited version
of it is *too* simple.

> In the long run, keepings things simple will often improve performance,
> because it makes them easier to optimize.

Given that the implementations of deconstruct and limited_deconstruct differ
only in the limit checks, I don't see how the existence of limited_deconstruct
affects the set of optimizations applicable to deconstruct, or the other RTTI
routines.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------