@normen said: I don't see the "much" here. A cast is pretty expensive on its own right if we're down to that level, you know that?difference in efficiency depends on the number of threads and the like JIT optimizes cast
@javasabr said: difference in efficiency depends on the number of threads and the like JIT optimizes cast
Hashmap lookups are constant time. The native call to currentThread() will dwarf hashmap lookup time.
a) your design is totally screwed up if you are accessing a ThreadLocal often enough for performance to matter (just grab the reference once and avoid the native call or pass the state properly instead of using globals).
b) the performance difference is small because the native call will take more of the time.
c) as hinted, you are abusing the idea of thread local storage.
I use local objects only in places where you would otherwise have to create new
ThreadLocal:
[java]public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null)
return (T)e.value;
}
return setInitialValue();
}[/java]
itās fast?)
This reminds me of jezek who wanted to make a āstackā for java and just made jbullet slow as hell with it ^^
Just go along the normal programming paradigms for java, those are being optimized. This kind of micro-optimization is pointless, time intensive and the results are not predictable. The compiler is WAY better than you at optimizing code.
@normen said: The compiler is *WAY* better than you at optimizing code.
I donāt think this can be repeated enough. And that goes for +90% of people.
also at that microscale, you canāt really say something is faster without quantitative data (stress testing) proving so, otherwise its all speculation (for what ever reason), as you donāt know exactly was is happening under the hood.
@javasabr said: LocalThread : Thread.currentThread() -> hashMap.get(thread) -> target instance; GameThread : Thread.currentThread() -> cast() -> get field instance
Above is bit wrong, thread local actually works by
Thread.currentThread().localMap.get(threadLocalPtr)
It is thread holding map keyed by threadlocals rather than threadlocal holding map keyed by threads. There is a weak reference involved there as well, to not block collecting threadlocals.
And as others told you - donāt optimize at this level.
@abies said: Above is bit wrong, thread local actually works by Thread.currentThread().localMap.get(threadLocalPtr) It is thread holding map keyed by threadlocals rather than threadlocal holding map keyed by threads. There is a weak reference involved there as well, to not block collecting threadlocals.And as others told you - donāt optimize at this level.
I am developing a game server in java for several years, all the optimizations that I use, I tested)
@javasabr said: I am developing a game server in java for several years, all the optimizations that I use, I tested)
Jezek thought so too ^^ And in his environment it looked as if he was right.
Really, trying to outsmart some of the most complex code in the world (JVM) and by now decades of experience going into javaā¦ Well, have fun, but its really not a wise move imo. Just because you understand one aspect well doesnāt mean you oversee the whole set of implications well.
@normen said: Jezek thought so too ^^ And in his environment it looked as if he was right.Really, trying to outsmart some of the most complex code in the world (JVM) and by now decades of experience going into javaā¦ Well, have fun, but its really not a wise move imo. Just because you understand one aspect well doesnāt mean you oversee the whole set of implications well.
I repeat once more, the local objects I use only in places where they are really beneficial, and not all in a row
@javasabr said: I am developing a game server in java for several years, all the optimizations that I use, I tested)
When the high level design is really bad then you will waste lots of time looking for these little things.
@javasabr said: I repeat once more, the local objects I use only in places where they are really beneficial, and not all in a row :)
But apparently you access them so often that itās a performance issue. = crappy design
1 Like
@normen said: This reminds me of jezek who wanted to make a "stack" for java and just made jbullet slow as hell with it ^^
Haha, yes I once even tried a primitive refelction based newInstance as a replacement (due to the stupid instrumentation step) and could not see any speed difference at all
Btw if you are rally sure and are able to see all implications, I dont get why you cannot figure out on how to inject your own thread into jme, (dont take this offensive, but i see a gap in skills here, that at least make me wonder if yu really see all implications)
1 Like
@Empire Phoenix said: Haha, yes I once even tried a primitive refelction based newInstance as a replacement (due to the stupid instrumentation step) and could not see any speed difference at all :)Btw if you are rally sure and are able to see all implications, I dont get why you cannot figure out on how to inject your own thread into jme, (dont take this offensive, but i see a gap in skills here, that at least make me wonder if yu really see all implications)
solution to this same question I already wrote here