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
