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
