On Wednesday, 10 July 2013 at 18:10:19 UTC, Sean Kelly wrote:
> It would have to be done in a way that avoided allocating though (similar to core.demangle), to be in core.

This would be really easy to do if enum string[] = [...]; didn't allocate at runtime.

Unbelievable.

On Thu, Jul 11, 2013 at 03:24:05AM +0200, Adam D. Ruppe wrote:
> On Wednesday, 10 July 2013 at 18:10:19 UTC, Sean Kelly wrote:
> >It would have to be done in a way that avoided allocating though (similar to core.demangle), to be in core.
> 
> This would be really easy to do if enum string[] = [...]; didn't allocate at runtime.
> 
> Unbelievable.

I think this is a general problem of array and AA literals allocating at runtime (and sometimes *every single time* the literal is used). We really should have a way of generating array and AA literals in the object file so that no runtime allocation is needed.

Runtime-generated literals really should only be used when there are runtime variables involved in their construction, i.e., immutable x = [1,2,y] can't be allocated at compile-time if y is a runtime variable, but immutable x = [1,2,3] can and should be allocated at compile-time and saved in the object file.


T

-- 
What's a "hot crossed bun"? An angry rabbit.

On Thursday, 11 July 2013 at 01:32:33 UTC, H. S. Teoh wrote:
> I think this is a general problem of array and AA literals allocating at runtime (and sometimes *every single time* the literal is used).

Aye, it is. Even here it was doing it on every single loop iteration. Disgusting. I was hoping setting it as an enum would ctfe it and just be static data, but nope.


Anyway, I updated the file (forgive me if this posts multiple times, I tried last night but my internet died). It is up here now too:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/mangle.d


It is allocation-free, except for the keyword list literal. Ugh. (This could be avoided if I sorted it manually but meh i'm lazy). Uses static stack buffers for its scratch space.


Now handled more complex function signatures too, compile with -unittest and take a look.


I think this is probably all I'll do on this for now, but it should be pretty useful as is.

On 2013-07-11 14:39, Adam D. Ruppe wrote:

> Aye, it is. Even here it was doing it on every single loop iteration.
> Disgusting. I was hoping setting it as an enum would ctfe it and just be
> static data, but nope.

Have you tried:

enum string[23] _primitives = [ ... ];
static immutable primitives = _primitives;

-- 
/Jacob Carlborg

On Thursday, 11 July 2013 at 16:38:48 UTC, Jacob Carlborg wrote:
> enum string[23] _primitives = [ ... ];
> static immutable primitives = _primitives;

Cool, a variant of that did work. Thanks!

Now it is 100% heap allocation free.

BTW if you guys are wondering how I found the allocations, it was pretty simple:

dmd mangle.d -debug -gc
gdb ./mangle

break gc_malloc
break gc_qalloc
r


Then when it breaks, do "where" and see what called the gc alloc. Then hit "c" to continue and repeat until you've found and fixed them (or ignored if they are in druntime).

On Jul 11, 2013, at 9:56 AM, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Thursday, 11 July 2013 at 16:38:48 UTC, Jacob Carlborg wrote:
>> enum string[23] _primitives = [ ... ];
>> static immutable primitives = _primitives;
> 
> Cool, a variant of that did work. Thanks!
> 
> Now it is 100% heap allocation free.

Sweet!  And to be fair, I'm fine with heap allocation as a failsafe.  What's important is that if the user provides a sufficiently large input buffer, then the routine doesn't allocate.  That way, the GC and other sensitive parts of the code can use these functions if needed.

On Jul 11, 2013, at 10:00 AM, "Adam D. Ruppe" <destructionator@gmail.com> wrote:

> BTW if you guys are wondering how I found the allocations, it was pretty simple:
> 
> dmd mangle.d -debug -gc
> gdb ./mangle
> 
> break gc_malloc
> break gc_qalloc
> r
> 
> 
> Then when it breaks, do "where" and see what called the gc alloc. Then hit "c" to continue and repeat until you've found and fixed them (or ignored if they are in runtime).

I usually grep the output of obj2asm.  Your way sounds easier :-)

On 2013-07-11 19:00, Adam D. Ruppe wrote:
> BTW if you guys are wondering how I found the allocations, it was pretty
> simple:
>
> dmd mangle.d -debug -gc
> gdb ./mangle
>
> break gc_malloc
> break gc_qalloc
> r
>
>
> Then when it breaks, do "where" and see what called the gc alloc. Then
> hit "c" to continue and repeat until you've found and fixed them (or
> ignored if they are in druntime).

That's a good tip. I'm going to start using that.

-- 
/Jacob Carlborg