On Fri, 12 Apr 2013 09:38:53 +0100, Vladimir Panteleev
<vladi...@thecybershadow.net> wrote:
On Friday, 12 April 2013 at 08:26:48 UTC, Manu wrote:
Again, I'm just suggesting possibilities, and trying to illustrate that
it's a STANDARD library, you can never predict where users will want to
use
it.
So you are talking about an imaginary system where memory allocation is
expensive but process creation is cheap.
It's impossible to design and optimize software for some intangible
goals. None of the systems that D targets, or aims to target, meet that
criteria.
I don't understand why you're so "against" these comments. There is no
real "argument" here, you both want std.process to be as good as it can be
and it will clearly be better if it performs faster and allocates less.
Yes, premature optimisation is generally frowned upon in "user" code, but
library code should ideally be optimised. Should this percieved lack of
optimisation prevent it's inclusion now, no because optimisation wont
change the API (it may extend it however).
Can you perhaps quantify how any of those things would be reduced by
addressing at least the details I highlight?
I'm basically advocating making a habit of using the stack where
possible.
It's not exactly hard, or cryptic.
Yes. However, I suggest the following instead:
Please rewrite some part of std.process with performance in mind, and
post it here for review. This way, we can analyze the benefits and
drawbacks based on a concrete example, instead of vapor and hot air.
Fair point, after all someone has to do the work and it seems logical that
the person with the most understand of the issue should so it. Whether he
has the time however is the Q/problem.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/