Should we always inline newByteArray#?
marlowsd at gmail.com
Thu Mar 13 21:42:03 UTC 2014
On 13/03/14 21:36, Johan Tibell wrote:
> On Thu, Mar 13, 2014 at 10:24 PM, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> wrote:
> It's a bad idea for large arrays (>= 3k), because when allocated via
> allocate() these arrays get a blocked marked with BF_LARGE that
> doesn't get copied during GC.
> It might be a good idea for arrays less than this size (including
> the header). It's a bad idea if the size isn't statically known,
> Sorry for not being clear. We will only do the inline *allocation* if
> the size <= 128 bytes. I'm talking about always inlining the *code*
> (whether it contains a call to allocate or not). In one case we will
> inline a definition reusing the heap check. In the other case we will
> inline a definition that calls allocate.
Oh I see, sorry for misunderstanding. In that case it's a
straightforward code size / speed tradeoff. When a similar case came up
recently (PAP optimisations) I turned it on for -O2 only. Someday I'd
really like to have a -Os that would allow us a bit more control over
decisions like this.
More information about the ghc-devs