5 ms·
A big part of that is that this benchmark is not representative of what general software is like, not in Go, not in Java. For one thing, most software isn't ch
by yumaikas 7y ago
A big part of that is that this benchmark is not representative of what general software is like, not in Go, not in Java.
For one thing, most software isn't churning on an array of integers. It's allocating and managing various types of objects.
I haven't written a ton of java, but I suspect that the various reflection-heavy frameworks also impose a lot of overhead into the resulting software that isn't necessarily inherently part of Java the language.
- slaymaker1907 7y agoReflection actually isn’t too inefficient, especially compared to using dynamic languages. I think a lot of the inefficiency is a bunch of small inefficiencies which combine together to make it very heavyweight.
- chrisseaton 7y ago> Reflection actually isn’t too inefficient My understanding is that it's completely uncached. It couldn't be any less efficient.
- kasperni 7y agoThe overhead of, for example, invoking a method via reflection is measured in single-digit nanoseconds. Still not as fast as direct invocation, but unlikely to be a bottleneck unless you perform 10-of-millions of them per second.
- LgWoodenBadger 7y agoActually finding the method via reflection is the time consumer. Once you have the method reference, actually invoking it isn’t any different than a regular method.
- sk5t 7y agoAlthough I can't tell you why, it's been my experience that firing a simple method via reflection in both .NET and the JVM is roughly 2x the time of direct calls (or of calls via the 'dynamic' keyword in C#).
- twic 7y agoObtaining a Method object is, I think, pretty slow. But calling through one is fast - I'm not sure what happens exactly, but after some number of calls, some sort of JITting or some such happens and a call via a Method object is as fast as as through a handwritten equivalent (which does the same unpacking of arguments etc).