Joel de Guzman wrote:
Joel wrote:
I'd like to see more tweakable parameters for specific uses. I frequently deal with different number expansions in a case to case basis. For example, is it possible to have arity 3 for function X and arity-5 for function Y? A single number seems wasteful if I'm sure that a certain use needs only a few. Is that possible? Yes, I think so. And it turns out to be a very good idea, as it potentially makes overload resolution *a lot* faster. Here comes the benchmark compiling do_the_bind.cpp, ported to use the forward adapter with gcc:
Arity=8 preprocess
real 0m1.384s user 0m1.270s sys 0m0.109s
preprocess, compile, link
real 0m12.405s user 0m11.769s sys 0m0.540s
Arity=4 preprocess
real 0m0.918s user 0m0.454s sys 0m0.081s
preprocess, compile, link
real 0m1.949s user 0m1.653s sys 0m0.268s
Wow that's interesting. Is the trend exponential? Can't really tell with just 2 sample points.
Yeah, seems so: 4 -> 1.4 5 -> 1.5 6 -> 2 7 -> 3 8 -> 11.2 (compile & link time only) And these are just a few calls - we can easily have a higher constant in practice...
Interestingly preprocessing is a minor concern and so we could even provide means to take our pick at compile time (as opposed to preprocessing time).
Not so fast. Don't forget EDG.
No panic, I will also allow fractional preprocessing :-). The idea to (almost) mostly pay for what one knows to use at compile time (rather than what one assumes one might need at preprocessing time) makes compile time control a tempting feature to have, however. Regards, Tobias