On 12 April 2013 21:00, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

Consider the following hypothetical decisions and outcomes:

1. std.process is left at is. One user is angry / turned away because it performs 0.1% slower than it can be.

2. std.process is rewritten to minimize allocations. Code complexity goes up, new improvements are challenging to add; bugs pop up and go unfixed for a while because fewer programmers are qualified or willing to commit the effort of making correct fixes. More people are angry / turned away from D because its standard library is buggy.

Of course, the above is an exaggerated illustration. But would optimizing all code left and right really make more D users happier?

Just to be clear, I'm not arguing optimisation for performance here, I'm arguing intolerance for __unnecessary__ allocations as a policy, or at least a habit.

There's a whole separate thread on the topic of fighting unnecessary garbage, and having the ability to use D with strict control over the GC and/or allocation in general.

If std functions have no reason to allocate, why should they?

There's also the question of priorities. Would you rather than effort is spent on optimizing std.process (and dealing with all the fallout from any such optimizations), or working on something that is acutely missing and hurting D?

If it's somehow hard to put a string on the stack, then there may be a hole in phobos. I'm not suggesting changes that are somehow hard to implement, or obscure in some way... they should be utterly trivial.

D is a systems programming language, there is hope that it will penetrate a wide range of systems and environments - sure in many cases a little bit of memory use or performance loss is unimportant, but for many it will be the decisive factor which makes D unusable there.

This is surely an exaggeration.

D does not attempt to please everyone out there who is choosing a programming language for their next project. There is no such language, nor can one exist. One has to accept that D has a number of goals, none of which are absolute, but merely point towards a certain, but not overly specific, point in the multidimensional matrix of trade-offs. D never was about achieving maximum performance in all possible cases.

And I never suggested we scrap phobos and rewrite it so it maximises performance at all costs. I highlighted, and suggested trivial changes that would make a big difference and don't hurt anyone. If it were habit of phobos devs to generally consider and try and avoid unnecessary allocations (almost all of which would be approached by using the stack wherever applicable), the situation would be much better in general. End-users can write D code however they want, but phobos should strive to be usable in as many types of software as possible, otherwise what good is a standard library?