Thoughts about D

[Jonathan M Davis]

On Wednesday, November 29, 2017 19:29:56 Walter Bright via Digitalmars-d 
wrote:
> On 11/29/2017 7:15 PM, Jonathan M Davis wrote:
> > I wouldn't have expected assertions to cost much more than however much
> > it costs to evaluate the expression being asserted unless the assertion
> > fails. Now, even that can slow down a program a fair bit, depending on
> > what's being asserted and how many assertions there are, but it's not
> > something that I would have expected to vary particular between C and
> > D. It doesn't surprise me that the generated code would be larger than
> > you'd get for the same assertions in C because how assertions are
> > handled when they fail is quite different, but I would expect the
> > assertions themselves to cost about the same in terms of performance as
> > long as they don't fail. What's going on that's making them so much
> > worse?
>
> The code *size* causes problems because it pushes the executing code out
> of the cache.

Well, given that assertions would normally be used in a debug build where
you generally don't optimize, and the debug symbols are compiled in, I
wouldn't think that that would matter much in most cases.

> Another issue (I should check this again) was doing null
> checks on member function calls, which is not necessary since if they're
> null it'll seg fault.

I didn't think that we _ever_ checked for null on accessing members (though
as I understand it, we actually do need to if the type is large enough that
segfaults don't actually happen when dereferencing null - at least, we need
to check for null in those cases in @safe code, or the code isn't really
@safe).

- Jonathan M Davis