3 ms·
It definitely won't match the performance of normal field access, just as passing an unbound method reference won't be as fast as calling it directly, or callin
by morelisp 4y ago
It definitely won't match the performance of normal field access, just as passing an unbound method reference won't be as fast as calling it directly, or calling through an interface won't be as fast as calling on a concrete type.
The best performance you'll get is probably from putting the fields together into a substructure and passing around pointers to that. Which doesn't need any reflecting or additional language scaffolding.
- Groxx 4y agoWhy would an unbound method be any different than a bound one? They both involve exactly the same function table lookup, and execute against data that's somewhere else.
- morelisp 4y ago> They both involve exactly the same function table lookup, and execute against data that's somewhere else. It's not that it's bound vs. unbound, it's that you passed it somewhere else so the call is necessarily dynamic. It would happen with non-method functions also. (In neither case is there a "function table lookup" - that's rather if you call through an interface / generic dictionary.) A bound one would be even more expensive because you also have to allocate a closure for the receiver. The point is: You want some non-compile-time behavior, whether that's a function or field access, you're going to pay more. That time, not regular field access, is what should be compared to reflect performance.
- Groxx 4y agoAh, yeah, it's definitely optimization-defeating (or more-so in any case). Completely agreed on that.