Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Performance hit of Thread.currentThread()
This is great to know.  I did some profiling on Win 10, and indeed it does appear that Thread.currentThread() is basically free.

It also shows that if I run code in a loop like this:

if (!display.isDisposed()) {
  if (Thread.currentThread() == display.getThread()) {
  // do something
  }
}

vs like this (avoid the synchronization by caching the value of display.getThread() and ignore isDisposed())

if (Thread.currentThread() == swtThread) {
  // do something
}

then I see a 30% speed improvement in some of my code - benchmark here, if you're curious: https://github.com/diffplug/durian-swt/blob/de1dd97e2e17e161def5c59f1307beab08a8b38b/test/com/diffplug/common/swt/SwtExecProfile.java#L41-L105

> There were some patches that were provided but they weren't accepted due to problems with adding new APIs to the builds not being testable.
Is it worth revisiting this?  I'm sure it won't be a 30% performance improvement, since I'd imagine most of the time is getting sunk on the native-code side.  But for code that's doing a lot of java-side stuff, if you could cut the overhead of lightweight calls by 30%, that seems worth grabbing.

ᐧ

Ned Twigg
Lead Software Architect, DiffPlug LLC
540-336-8043
340 S Lemon Ave #3433, Walnut, CA 91789

On Thu, Jun 9, 2016 at 3:57 PM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
I suspect the advice is no longer necessarily correct or has been proven. Although there may be syscalls involved it is certainly the case that the native implementation can be fast-unlined through an intrinsic and it does not have to bail to an interpreter at all. 

https://github.com/dmlloyd/openjdk/blob/2368260acfb88a776d9d759cd1a30f4661e6e195/hotspot/src/share/vm/opto/library_call.cpp#L686

In addition almost all UI updates (including Swing, AWT, and the platforms that SWT supports) require that they be done from the correct thread so this isn't new at all. 

Where it could be optimised is removing the synchronised keyword of the get display thread, and/or add a new method "isDisplayThread()" without synchronisation so that there is less contention for the synchronised block in the Display class itself. There were some patches that were provided but they weren't accepted due to problems with adding new APIs to the builds not being testable. 

Alex

Sent from my iPhat 6

On 9 Jun 2016, at 23:10, Ned Twigg <ned.twigg@xxxxxxxxxxxx> wrote:

Most SWT method calls start with `checkWidget()`, which calls `Thread.currentThread()`.

I haven't profiled it myself, but Lint4j claims that this is an expensive method call:

Has anyone quantified the performance impact of these calls?

An alternative would be to introduce an `@SwtThread` annotation, and use `javaagent` to enable a "debug mode" where the thread is checked, and then not check them at runtime for release builds.

Here is a project which uses a similar approach for Swing:

Just curious if anyone else has looked at this :)

-Ned
ᐧ
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev

Back to the top