assert(expression, error)

[Jonathan M Davis]

On Saturday 12 February 2011 08:38:45 spir wrote:
> On 02/12/2011 05:27 PM, Jonathan M Davis wrote:
> > Aside from enforce, this function is a one-liner. It's obvious that it
> > should be inlined and that it _would_ be inlined if enforce isn't used.
> > But if I were to use enforce, it couldn't be inlined. It's situations
> > like that which really bother me. enforce is definitely and obviously
> > harming code efficiency in such a case.
> 
> Hello again Jonathan,
> 
> Maybe a good use case of what I asked for in another thread: feedback from
> the compiler about whather a given func is inlinable. Imagine I don't know
> enforce is problematic. After all, at first sight, I can see no obvious
> reason (maybe from lack of knowledge). Then, how can one know? Could
> happily let it externalisable persuaded it would /for sure/ be inlined.
> In your case, tough, I think it's not problematic since there are few
> chances for the func to represent a significant proportion of run time (I
> guess ;-). In my case, it a func called by a parser's Node constructor!
> Typically a major part of a parser's runtime is, precisely, generating
> millions on Nodes every second...

There are tons of functions out there which are one or two lines long which 
should be inlined. Setter property functions and constructors are often good 
examples (though constructors do tend be a bit longer than one or two lines). 
Whether they're used often is certainly relevant (and the situation is obviously 
far worse if the _need_ to be inlined and aren't), but they should be inlined 
regardless. As long as the inliner is smart, however, it shouldn't be a problem. 
The problem here is an issue with how the current inliner works. It doesn't and 
shouldn't require a language change in the sense that you'd force inlining or 
whatnot. What it needs is for the inliner to be improved.

And while the example I gave may or may not actually result in being a 
performance problem for someone, I definitely can't assume that it won't be. It's 
in the standard library after all, and who knows what people are going to use it 
for. But I wasn't really trying to single out anything about std.datetime with 
that example. It's just that it was an easy example to give, since I already had 
the code. The issue is that using enforce in what should be a one line function 
(without the enforce) suddenly makes the function un-inlineable when you add the 
enforce call, and that _can_ seriously harm performance.

Regardless, the way this sort of problem is found if you're not already aware of 
lazy causing problems with inlining is that you profile your code. And if it 
shows that you're spending a lot of time in a particular function, you try and 
figure out how to make that function more efficient. Ultimately, that could mean 
looking at the assembly code, which _would_ tell you whether the function was 
inlined or not. I do agree that having to go so far as to look at the assembly 
code figure out whether a function is being inlined is not desirable, but I also 
don't think that you should _have_ to try and figure out whether a function is 
inlined. The compiler should be smart enough to deal with that. And it often is, 
but it also definitely has room for improvement. lazy parameters are a prime 
example of that.

- Jonathan M Davis