DI Generation Needs your Help!

[Adam Wilson]

On Wed, 14 Mar 2012 14:42:54 -0700, Alvaro <alvaroDotSegura at gmail.com>  
wrote:

> El 14/03/2012 22:13, Adam Wilson escribió:
>  > On Wed, 14 Mar 2012 13:45:13 -0700, Alvaro <alvaroDotSegura at gmail.com>
>  > wrote:
>  >
>  > The problem is that in DI generation, at least as near as I can tell,  
> D
>  > has now idea how big a function is during DI generation. In my
>  > experience it was keeping all functions not just small ones. And  
> frankly
>  > DI generation is targeted at library builders who are well aware of  
> the
>  > inlining trade-offs. And then comes the question of how do you define
>  > "small functions" to an adequately technical level.>
>
> OK, I rechecked. DMD -H is at least omitting function bodies containing  
> foreach() loops (and maybe other cases). Maybe that led me to assume  
> things.

Hmmm, I hadn't seen it do this. But the whole point of DI files is to  
create an interface to compiled libraries, not be the absolute fastest it  
can be. It is generally accepted that you are going to take a minuscule  
(and on modern machines it is truly minuscule) hit every time you cross a  
library boundary, unless you import the whole source of said library,  
which is functionally what DI generation does now.

> AFAIK some C++ compilers use heuristics (don't really know what that is  
> exactly) to decide what "small functions" deserved automatic inlining.

Those heuristics are in the semantic analysis step and I really don't  
think building the DI file against the constantly changing AST during  
semantic analysis is a wise idea. DI's get built before that, and as such  
do no have access to those heuristics. If the compiler is doing something  
it's based on its own special, and limited analysis prior to the semantic  
analysis (I think I know which function is doing this, but it doesn't work  
very well at all). Also, trying to build DI's during semantic analysis  
would most likely drastically slow down the compiler as the DI's would  
need to be constantly updated to make the AST changes. Basically, it's an  
incredible amount of work for a minuscule speed improvement in the final  
step. There are areas of D that are MUCH more ripe for speed improvements  
than inlining in DI files ... *cough*GC*cough*

> And well, C++ library builders are aware of that and usually keep the  
> small functions they want inlined in the header file (e.g. in the class  
> declaration). I can see a lot of cases where D libraries would benefit  
> from allowing some of their functions to be inlined. Think of  
> @properties, they're often pretty short.

Well, that's where the do-it-yourself part into play. This is an automated  
system for generating headers based on a naive AST. It will not be  
perfect. But C++ doesn't even have that and they have to hand maintain  
everything, so pretty much anything we do is an improvement. :-)
@properties are a valid concern, and also one that can be addressed in the  
current method of DI generation as they are a valid token that can be  
checked for and excluded. If the community wishes for @properties to  
retain their implementations that would an easy thing to do. But be  
warned, you wont be able to call private functions as those are dropped  
COMPLETELY from the DI file. Private data will of course be accessible.

> Other than this detail, the improvement in DI generation is very welcome.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/