cameron <cdor...@gmail.com> writes: > the megamorphic call site hypothesis does sound plausible but I'm > not sure where the following test fits in.
... > I was toying with the idea of replacing the EmptyList class with a > PersistsentList instance to mitigate the problem > in at least one common case, however it doesn't seem to help. > If I replace the reverse call in burn with the following code: > #(reduce conj (list nil) %) > I get the same slowdown as we see if reverse (equivalent to #(reduce > conj '() %)) Ah, but include your own copy of `conj` and try those two cases. The existing clojure.core/conj has already been used on multiple types, so you need a new IFn class with a fresh call site. Here are the numbers I get when I do that: w/o EmptyList : smap-ms 6.1, pmap-ms 1.2, speedup 5.26 w/ EmptyList : smap-ms 10.4, pmap-ms 16.2, speedup 0.64 w/o EmptyList : smap-ms 10.5, pmap-ms 16.3, speedup 0.64 That said, I’m slightly less convinced than I was earlier. I’m having difficulty producing a minimal example demonstrating the issue, and the results wmjosiah reported for modifying their actual code are disheartening. I just don’t have anything else which begins to explain the transition from speedup to inverse speedup in the above benchmarking sequence. -Marshall -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en