Re: Feedback request: priority queues in containers

I'd concur, but I haven't been able to install Criterion yet. =( Let me rewrite things with BenchPress, and see what happens. I should add, though, that I think C *is* as optimized as D. In particular, some of the tricks that worked with D only worked because of the way the spines were arranged. (For instance, unrolling the children incrementally was a trick that really worked because the children and the trees in the spine were lined up, which meant that it needed the Skip combinator.) Simon: I wasn't sure what to do there, because e.g. Data.Map, I think, is strict that way. I prefer the lazy way, though, so I certainly don't mind keeping it lazy =) Louis Wasserman wasserman.louis@gmail.com http://profiles.google.com/wasserman.louis On Wed, Mar 17, 2010 at 4:04 AM, Johan Tibell wrote:

I really recommend using Criterion to get rid of some of the many problems associated with benchmarking.

http://hackage.haskell.org/package/criterion

Cheers, Johan

On Wed, Mar 17, 2010 at 9:35 AM, Jim Apple > wrote:

...

I should also note that these timings are quite temperamental on my computer; using profiling or removing the performGC calls can make C faster than D and B faster than A.

...

Binomial priority queue timings (in milliseconds, averaged over 20 runs) A: Simple Brodal-Okasaki list implementation: 199.3697 B: Wasserman nested type implementation, simple functions: 235.0143 C: Wasserman's 'Quick' list implementation: 179.7227 D: Wasserman's proposed nested type implementation: 163.47515

D is still the fastest. However, A is a good bit faster than B. Is it possible that C would show a similar advantage over D if it were optimized as carefully as D?

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries