Improves Growth Factor

[chris-huxtable]

Based on finding the growth coefficient of IO::Memory was 2.0 and the information referenced in this article.

[Sija]

Btw, similar optimization could be also applied to Array.

[chris-huxtable]

Yep :)

I want to sort it out here first then apply it anywhere else it could be useful.

[chris-huxtable]

I am having 2 of my machines do every value 1.1 to 2.0 at steps of 0.01 just on the off chance there might be something better. The results I will put in Gists.

• macOS 10.13
• OpenBSD 6.3

I will update them with the full results in the morning.

Edit: Based on the current results I think my results may be an artifact of my testing procedure. I will dig deeper.

Edit: My testing method was flawed. Please ignore it.

[ysbaddaden]

Don't run benchmarks but analyze bdwgc to understand how it does allocate memory, and more specifically how much more memory does it allocate than required.

Problem is, once you're tied to a GC memory model, it will fall flat with another memory allocator. For example with my Immix GC the allocation is always rounded to a word size, that is 4 or 8 bytes depending on 32 or 64-bit arch. You may be lucky and have enough room after the current allocation, but it's random chance.

[chris-huxtable]

I intend to go deeper when I have time. If it’s just a constant I don’t think it would be to difficult to set it based on the GC’s memory model.

[ysbaddaden]

In fact, with Immix GC I always reallocate and will always (unless the size didn't change), because the current thread allocator probably doesn't own the memory block anymore.

So, to me, the growth factor is mostly about growing enough vs wasting space in common collection use cases.

[chris-huxtable]

Looking further into this issue its largely about wasting space. That being said The growth coefficient should still be less then 2.0 so that reuse can potentially happen. I know @ysbaddaden has said that IMMIX doesn't reuse its memory but as far as I have been able to ascertain boehm does as do many others. If we switch from boehm I think this should be re-evaluated.

There is an interesting discussion on growth rates on stack overflow which also references the FBVector like I referenced above .

Until we switch from boehm I like the Idea of using Phi (φ) 1.618033987 as its less then 2.0 allowing reallocation, but will have an intermediate rate of growth keeping reallocations low. Also because its the golden ratio.

[jkthorne]

@chris-huxtable are you still working on this I am interested if this can still be a performance improvement.

[chris-huxtable]

I am not currently. But I could take another shot at it if there is interest.

[jkthorne]

I mean I am interested in it. Maybe someone from the core team could weight in. I think some preliminary benchmarks might be compelling.

[chris-huxtable]

It's kind of a difficult thing to test. If you don't inter-splice a number of mallocs as you grow the array when testing and manage to do so consistently you end up with no difference (realloc involves no copying) or inconstant results (realloc inconsistently copies.

[chris-huxtable]

Beyond performance improvements I think it makes sense to go to a more conservative growth factor just for memory efficiency.

@ysbaddaden, @straight-shoota, anyone else relevant - Would a PR which sets a more conservative growth factor of Phi (φ) 1.618033987 be accepted in principle, assuming it works and meets any other standards of quality?

Note: I like 1.618 as its an approximation of Phi (I realize this is aesthetic and a form of naturalistic fallacy). Apple uses 1.625 in NSMutableArray. Others have noted their use of 1.6. Really the factor should be able to be tuned (any PR I submit would use an easily adjusted constant).

[straight-shoota]

Sure, performance optimizations are always welcome.

It's just optimizations can easily be added later, and I think at the moment we'd like to put a stronger focus on bug fixes and features. Feel free to go ahead, though.

[chris-huxtable]

@straight-shoota - Sounds good. Just don't want to waste my time and end up in a 9 mouth back and forth about it. Best to know if its acceptable before hand.

[rdp]

Are there any benchmarks showing performance improvement?

[chris-huxtable]

It's hard to contrive a comparison. It's really more about efficiency.

[caspiano]

I believe this can be closed in favour of #11482

[straight-shoota]

They're definitely related. But this one is about IO::Memory, while #11482 only affected Array.