Simon Peyton-Jones wrote:
| The thesis suggests that using Uniplate with the fastest instances
| will be around 30% slower than manual operations, but using SYB based
| instances will be 300% slower. In practice, these are benchmarks on
| generic traversals, and may not accurately reflect how people using
| the libraries in practice - the bottlenecks may be elsewhere.
OK, so despite my recent exposure memory does not serve! A factor of 10
overhead for Uniplate-over-Data, as opposed to Uniplate directly, is much
bigger than I thought.
Still, as you say, it's the API that matters. We can always generate Uniplate
instances later if they turn out to be the bottleneck.
That approach worries me. We could add generic traversals all over the
place, and while none of them is a "bottleneck", the overall effect could
be quite significant.
The right approach I believe is to keep an eye on compile times when making
these kind of changes, and if at any point the compiler slows down by a few
percent, then back off. Timing a compile of GHC itself is good for this.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
