<div dir="auto"><div>Thanks! I'm still going to feel free to pretend I get arrays for free :-). I'm guessing I'll get some reused ones from the Haskell allocator, and the OS is of course free to do clearing work on another core. It'd be awfully nice to have a way to get "incrementally-cleared" arrays of pointers, but that would require a new heap object type, which would be a lot to ask for.<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 26, 2020, 8:56 PM Bertram Felgenhauer via Glasgow-haskell-users <<a href="mailto:glasgow-haskell-users@haskell.org">glasgow-haskell-users@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">David Feuer wrote:<br>
> I'm looking to play around with an array-based structure with<br>
> sub-linear worst-case bounds. Array is pretty awkward in that context<br>
> because creating a new one takes O(n) time to initialize it. Is that<br>
> all true of newByteArray, or can I get one with arbitrary garbage in it<br>
> for cheap?<br>
<br>
newByteArray# does not actively clear memory.<br>
<br>
However, for large arrays, I think the memory is likely to be freshly<br>
allocated from the OS, and the OS will have cleared it for security<br>
reasons.<br>
<br>
Cheers,<br>
<br>
Bertram<br>
_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org" target="_blank" rel="noreferrer">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users</a><br>
</blockquote></div></div></div>