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.

Reply via email to