Rereading my last post on compile-time performance, the thought leaps out at me: if I don't want to rely on users setting a switch to control whether optimization happens or not, then I should only optimize functions or templates if I know they are going to be used often enough to justify it. That strongly suggests I ought to be doing lazy (or just-in-time) optimization. It doesn't seem difficult in principle: just count entries to a function or template and invoke the optimizer when the counter hits (say) 50. Need to be careful about multithreading, but I'm sure it can be done. There are a few optimizations, like extracting global variables, that aren't local to a template or function, and this complicates the issue a little, but it doesn't sound all that hard.
|
|
||||||||
Just-in-Time Optimization
Comments
Re: Just-in-Time Optimization
I think this is an excellent idea, and I have had similar in mind for possible code generation for a data binding tool. The reasoning is along the lines that resources used for generating specific code to replace data-driven (and reflection-using) must be worth it: new class will be created, and speed benefit is likely just incremental (less than 2x throughput).
So I was thinking of similar counter-based approach; and perhaps just JITing one class-handler at a time (top match). I suspect that a simple solution is plenty good at first. I'd be interested in how your solution works, if and when you get a chance to implement it. |
Search
Recent Comments
Recent Articles
Month Archive
|
|||||||