# Push!, and interfacing to the runtime library

**URL:** https://discourse.julialang.org/t/push-and-interfacing-to-the-runtime-library/7461
**Category:** General Usage
**Tags:** performance
**Created:** [December 2, 2017, 7:54pm UTC](https://discourse.julialang.org/t/push-and-interfacing-to-the-runtime-library/7461 "2017-12-02T19:54:51Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)
#### Post date: [December 3, 2017, 3:02pm UTC](https://discourse.julialang.org/t/push-and-interfacing-to-the-runtime-library/7461/3 "2017-12-03T15:02:06Z")

</div>

I think using this code would be a terrible idea, in view of yuyichao’s comments in [https://discourse.julialang.org/t/why-so-many-internals-in-c/6119](https://discourse.julialang.org/t/why-so-many-internals-in-c/6119), and in view of [https://discourse.julialang.org/t/unsafe-store-sometimes-slower-than-arrays-setindex/7166](https://discourse.julialang.org/t/unsafe-store-sometimes-slower-than-arrays-setindex/7166).

That is, my example is just a PoC that at least 30% speedup for push! are available if we manage to inline the fast path (avoid the ccall, avoid checking array flags because type-inference tells us all). Same should apply for pop!.

We gain even more if we acknowledge that Vector and higher-dim Arrays are different:  
Vectors need no more doubling of length=nrows, and tiny vectors (up to 4\*sizeof(Ptr)) can be stored inline (they fit into the same cache-line! Miss avoided if we need to iterate over a large number of Vectors, many of which are small! This is actually something I do a lot: variable-arity trees where most nodes have very few or zero children). Alternatively, one could use the shrunk vector\_T to store two of them per cache-line (but I think inline storage gives a bigger plus).

Higher-dim arrays free the offset for an additional 32 bits of info. Not sure what to do with that; maybe store ndims, so that nospecialize on the number of dimensions becomes possible? Maybe make them user-available for locks?

Unfortunately I don’t feel comfortable enough with the C base to even attempt to separate array and vector or do a clean improvement.

I think the most pragmatic way to get a fastpush would be to copy the approaches for setindex!-non-bitstype and length for grow\_at\_end and shrink\_at\_end (that is, there is a special case in code-gen that emits the fastpath for inlining, and if this fails we do a library call for rooting of the setindex!ed object).

PS. Also, this needs to be different on 32 bit systems.

---

_[View the full topic](https://discourse.julialang.org/t/push-and-interfacing-to-the-runtime-library/7461)._