Sure, absolutely - there's nothing like profiling to see what's actually going on and his recommendation seems sound either way, I just thought the information was interesting.
On 11 August 2015 at 23:44, Zach Tellman <ztell...@gmail.com> wrote: > It's fluid, but the output that Norman uses in his post (and that > motivated the changes to Aleph) were from the JVM explicitly saying "I > would have inlined this, but it was too big". That may not be true under > other circumstances, but you're only helping by factoring out uncommon, > large code branches. > > On Tuesday, August 11, 2015 at 2:01:59 PM UTC-7, Colin Fleming wrote: >> >> That's a really interesting post, thanks for that. I actually cornered >> Cliff Click at Curry On because I was interested in knowing how well the >> JVM inlined var indirection. The short answer is "it's complicated". But if >> the JVM does inline your method, then the var indirection shouldn't cost >> you as long as the var content is stable. >> >> Tom Crayford's great talk at EuroClojure also pointed out that another >> thing which affects inlining is the stack depth, which can mean you're >> damned if you do and you're damned if you don't when trying to refactor to >> help with inlining. However Cliff said that all these limits are pretty >> fluid - it's not like a method over 325 bytecodes will never be inlined, if >> it's identified as hot that limit goes way up, and a relatively cold method >> can still be inlined even if it's small. >> >> I'd actually love to sit down and test this with Clojure sometime, but I >> never seem to find time for it. >> >> On 11 August 2015 at 21:00, Zach Tellman <ztel...@gmail.com> wrote: >> >>> The inlining part is explained very well by this blog post >>> http://normanmaurer.me/blog/2014/05/15/Inline-all-the-Things/ >>> >>> As for why I left all the repetition in there, I tend to let code expand >>> before getting annoyed and compacting it. Sometimes there's a commit >>> between those two events, sometimes there's not. In this case, you get to >>> see how the macro/abstraction sausage is made. >>> >>> Happy to answer any other questions, >>> Zach >>> >>> >>> On Sunday, August 9, 2015 at 9:38:51 AM UTC-7, Lawrence Krubner wrote: >>>> >>>> >>>> Reid, thank you. I think you answer half the question. You make a good >>>> point about giving the JVM a way to better optimize a hot path. I think you >>>> are right about that. But, given the large amount of repetition between >>>> "chain'-" and "chain-" I'm wondering why this wasn't done with a macro? >>>> >>>> >>>> >>>> On Sunday, August 9, 2015 at 2:08:47 AM UTC-4, Reid McKenzie wrote: >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA256 >>>>> >>>>> Lawrence, >>>>> >>>>> This is just a theory, but in the interests of response time, the JVM >>>>> uses a large number of heuristics to determine what optimizations will >>>>> likely prove profitable. One of them is a budget for method size. I >>>>> would guess that lifting this code out into a separate fn made the JVM >>>>> see that it was optimizing a hot path between the main body and >>>>> several small but tightly related methods thus giving itself more >>>>> leeway to inline and optimize in ways that it would otherwise presume >>>>> are more expensive and not pursue. >>>>> >>>>> Reid >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@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+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
