On Sat, May 21, 2016 at 8:37 PM, FANG Colin <[email protected]> wrote: > @Steven My wrong usage of the phrase "memory layout" I guess. I meant heap > -> stack change (I thought this belongs to the term "memory layout"...). > Also, I had though as long as I don't use any variables from the global > scope the benchmark should be all right. > > @yichao The versioninfo for v0.5 in my case is
I didn't notice the `.y` in the code. That case is optimized before my PR. The change in allocation here is a pure optimization and doesn't change any API. > > Julia Version 0.5.0-dev+3305 > Commit c45175f (2016-03-29 03:51 UTC) > > > It seems to be a bit earlier than your commit. > > > > > > On Sunday, May 22, 2016 at 1:26:28 AM UTC+1, Yichao Yu wrote: >> >> On Sat, May 21, 2016 at 7:04 PM, FANG Colin <[email protected]> wrote: >> > immutable MyType >> > x::AbstractString >> > y::Int >> > end >> > >> > >> > @time for i in 1:10^5 MyType("a", 1).y end >> > >> > >> > In julia v0.4 >> > >> > 0.000813 seconds (100.00 k allocations: 3.052 MB) >> > >> > >> > In julia v0.5 >> > >> > 0.000003 seconds (5 allocations: 176 bytes) >> > >> > >> > It seems the memory layout for immutable which contains fields with >> > non-bit >> > types has changed in v0.5. >> >> I believe this is due to better allocation elimination in type >> inference[1]. This is exactly the case I meant by "allocation >> benchmark doesn't work". >> >> [1] https://github.com/JuliaLang/julia/pull/16021#issuecomment-213789309 >> >> > >> > >> > I would like to know more in details about such change, Where can I find >> > the >> > related issues, discussion in GitHub or mailing list?
