Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Remote Application Platform (RAP) » Feasibility of caching ThemeAdapter computations?
Feasibility of caching ThemeAdapter computations? [message #1835608] Tue, 08 December 2020 17:29 Go to next message
Linuxhippy Mising name is currently offline Linuxhippy Mising nameFriend
Messages: 71
Registered: July 2009

Recently I've found some time to profile a large RAP based application which I've always found to be slow (large UI, ~1.5s server response time) . The application is a bit layout-heavy, it triggers quite a few re-layouts - however what I found intriguing is that the profiler didn't report the time in the layout functions itself as a problem.

According to my profile, a lot of time (>50%) is spent in million calls to - which are called by the ThemeAdapters which are in turn called often multiple times by almost all sizing-related stuff.

The codepaths don't seem to be problematic themself, however it seems all those small inefficiencies each call add up:
- many repeated calls to checkWidget(), which invokes currentThread() each time
- access custom CSS classes via Widget.getData (causing another checkWidget) with short (or longer) running loop to compare keys
- Lookup in the ConcurrentHashMap

The code-path itsel looks well optimized, however it is quite a bit of complex (for the JVM) code which can be called frequently - and all the code does in most cases* is to loop up a few constants. (most Constraints seem to actially be StyleConstraints and VariantConstraints and very little ThemeAdapter-Classes seem to implement their own constraints (Toolbar seems to be one of the exceptions).

What I wonder: have there ever been plans / discussions to implement some kind of caching for the ThemeAdapter return values? What are the reasons why this hasn't been implemented.

Would the following idea be possible to implement: For Widgets where ThemeAdapters do not have custom Constraint implementations simply cache the return value and clear cache in case setData(CUSTOM_VARIANT is called.
So instead of a SingleTon, getThemeAdapter() could return a per-Widget ThemeAdapter, which could return cached values at subsequent invocations until a cache-invalidating event occurs (css variant chance, what else could cause this?).

With the approach the cache could be even made optional - depending on a config setting a caching or non-caching ThemeAdapter could be installed, depending on what is more important - working set size of throughput performance.

Feedback is highly appreciated.

Thank you in advance, Clemens

[Updated on: Thu, 10 December 2020 07:39]

Report message to a moderator

Re: Feasibility of caching ThemeAdapter computations? [message #1836542 is a reply to message #1835608] Thu, 07 January 2021 08:50 Go to previous message
Ivan Furnadjiev is currently offline Ivan FurnadjievFriend
Messages: 2426
Registered: July 2009
Location: Sofia, Bulgaria
Senior Member

we are caching some performance "critical" values on widget bases - for example Tree/Table. See Tree#LayoutCache internal class. Using caching is always tricky, because you always deal with outdated values. Doing this globally is a lot of effort and hard to maintain. If you have some suggestion please open an enhancement request and create some Gerrit changes with proposed solution.

Previous Topic:User's activity
Next Topic:Corrupted String size cache
Goto Forum:

Current Time: Thu Jun 20 16:29:22 GMT 2024

Powered by FUDForum. Page generated in 0.03464 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top