<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 3, 2016, at 10:20 AM, Jens Alfke via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 2, 2016, at 5:14 PM, Mike Ferenduros via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Personally I would be surprised if the malloc caused an actual measurable performance hit tbh.</span></div></blockquote></div><br class=""><div class="">It won’t be noticeable against a call to SecRandom, as noted, but there <i class="">are</i> other circumstances where it’s a big performance hit to put a temporary buffer on the heap. (Right now I’m working on some rather performance-sensitive database code in C++ where avoiding a few heap allocations per iteration has proven to be a big win.)</div><div class=""><br class=""></div><div class="">Does Swift have any solution for allocating stack-based array buffers?</div></div></div></blockquote><br class=""></div><div>There has been some work in the optimizer toward optimizing arrays onto the stack when they don't escape. In general, I would recommend sticking with the pointer allocate/deallocate methods if you need to directly control the destiny of the memory. If the allocate and deallocate occur unconditionally in the same function, it is possible to optimize the pair into a stack allocation. Using a local variable isn't a guarantee that you'll get stack memory, since closures may force the variable onto the heap, and furthermore subjects you to more aggressive semantic constraints on the underlying memory than you may want.</div><div><br class=""></div><div>-Joe</div><br class=""></body></html>