Where will D sit in the web service space?

via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 14 05:09:28 PDT 2015


On Tuesday, 14 July 2015 at 09:05:59 UTC, Laeeth Isharc wrote:
> Good for you!  I am not sure that suggesting people roll their 
> own as needed will be conducive to encouraging the adoption of 
> D for web services - or any other use - though.

I think you got me wrong here.

In general you should do most work on the stack and avoid 
allocations for temporaries.

For long-lived data you should try to condense your data into 
reasonably sized units to avoid fragmenting the heap. If they 
have the same lifetime anyway.

In most cases a good model +  a good malloc implementation is 
sufficient to get decent performance.

Occasionally you might need to preallocate and preinitialize 
objects and have them on a free list.

Even more rarely you need a dedicated allocator (e.g. shared 
memory), and if you need that you probably are capable of writing 
your own in short order or have messed up your data-model.

> That doesn't appear to have been the rationale for the 
> subsequently-diluted original idea for including custom 
> allocators in the non-GC STL.  I should have thought allocators 
> belong in the library because they are rather useful and most 
> of us would rather not have to bother to roll our own.

STL is inflexible, memory fracturing, exception ridden, 
reallocating crap, I only use the most basic features of it 
(arrays). Custom allocators in STL are bloated crap that makes 
writing my own ADT a much better alternative. (I've tried both, 
thank you;)

> Ok.  I don't see how the compiler can understand my problem 
> domain better than me, especially at compile time.

The ideal is: You collect runtime data by profiling, the compiler 
do analysis, you provide metainformation/constraints 
(optimization hints).



More information about the Digitalmars-d mailing list