| Feasibility of caching ThemeAdapter computations? [message #1835608] |
Tue, 08 December 2020 12:29  |
Eclipse User |
|
|
|
Hi,
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 WidgetMatcher.select/matches - 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 02:39] by Moderator |
|
|
| Re: Feasibility of caching ThemeAdapter computations? [message #1836542 is a reply to message #1835608] |
Thu, 07 January 2021 03:50  |
| Eclipse User |
|
|
|
Hi,
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.
Regards,
Ivan
|
|
|
Powered by
FUDForum. Page generated in 0.03548 seconds
Home