On 12 April 2013 22:30, Lars T. Kyllingstad <pub...@kyllingen.net> wrote:
> On Friday, 12 April 2013 at 11:37:14 UTC, Regan Heath wrote:
>
>> I've moved this to another thread to allay complaints.
>>
>
> Thanks!
>
> I completely agree that if code can be made more performant without a
> significant increase in complexity, then we should do so. While it is
> mostly (but not entirely) irrelevant in the context of std.process, it is a
> problem that should be tackled in Phobos as a whole. Several things
> could/should be done:
>
> It would be nice to have some sugar on top of alloca(), the use of which
> is usually considered bad practice. Someone (bearophile?) once suggested
> static arrays whose length is determined at runtime, which would be a great
> addition to the language:
>
> void foo(int n)
> {
> int[n] myArr;
> ...
> }
>
That's beautiful!
Furthermore, we need to get the allocator design in place. In SciD, I use
> David Simcha's region allocator to allocate temporary workspace, and it
> works really well. The only times I use 'new' is when I need persistent
> memory (e.g. for a return value) and the user-supplied buffer is too small.
> Phobos would greatly benefit from doing this too.
>
> Finally, an example from the new std.process which got some heavy
> criticism in the other thread:
>
> envz[pos++] = (var~'='~val~'\0').ptr;
>
> I have been operating under the assumption that the compiler is smart
> enough to make the above a single allocation. If it isn't, I would
> consider it a compiler issue.
>
Does it? I've not seen the compiler do that, although I'd like to think it
should be possible. 1 allocation is better than 3 I guess, however, I
wonder if that code could be restructured to use the stack aswell.
alloca() is really underrated! I can't imagine why people don't like it.
Perhaps some more helpers built around it might encourage its use? It does
feel a little bit 'raw', like malloc(). It implies some annoying casts.
