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 <javascript:>> > 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 >> <javascript:> >> 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 <javascript:> >> 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 <javascript:>. >> 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.
