Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 363285 - Performance: CellStyle.getFont() and CellStyle.setFont() are slow on large tables
Summary: Performance: CellStyle.getFont() and CellStyle.setFont() are slow on large ta...
Status: CLOSED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Scout (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-09 06:03 EST by Lukas Huser CLA
Modified: 2021-08-19 11:00 EDT (History)
2 users (show)

See Also:
zimmermann: indigo+
zimmermann: juno+


Attachments
Patch CellStyle: replace m_fontPattern with m_fontSpec (1.80 KB, patch)
2011-11-09 06:04 EST, Lukas Huser CLA
andi.bur: iplog+
Details | Diff
Patch FontSpec: make FontSpec technically immutable (1.91 KB, patch)
2011-11-09 06:05 EST, Lukas Huser CLA
andi.bur: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Huser CLA 2011-11-09 06:03:18 EST
Build: Eclipse Scout 3.7.1

Description: 
While profiling an Eclipse Scout application with jvisualvm, we found that one of the time consuming operations when displaying large table data is the FontSpec.parse() method. It is mainly called by CellStyle.getFont() when creating the table cells.

Steps to reproduce:
- You will need a table page which potentially displays a large amount of data (in our specific tests we consider tables with > 20'000 rows as 'large')
- Populate a table page with the data (i.e. through an unconstrained search)

Reproducible: always

Solution:
Eliminate the FontSpec.parse() method from the getter method CellStyle.getFont().
The proposed solution (see attached patch file) does the following:
- replace the internal font representation in CellStyle (replace the existing string representation m_fontPattern with a simple reference to a FontSpec object, m_fontSpec).

The following has been considered:
- Correctness: Occurrences of m_fontPattern in equals and hashCode methods can be safly replaced with m_fontSpec (because FontSpec overrides those methods as well)
- Memory consumption: Memory consumption is not affected by this change (verified with jvisualvm)
- Performance: performance is significantly improved when displaying large amount of data in table pages. In our tests we measured speed-ups of about 1/4 to 1/3 of the total time needed to display the data.
- Shared access to FontSpec objects: the existing getter always created a new FontSpec object, the existing setter released the reference to the passed input paramter. This behavior could be simulated with defense copies of FontSpec objects stored and returned by the getter and setter methods. However, this is not necessary as a FontSpec object is effectivly immutable. To make this fact clear, I attached another patch file which makes FontSpec also technically immutable (make member fields final, remove empty constructor).

Attached files:
org.eclipse.scout.rt.client.ui.basic.cell.CellStyle.java.patch
org.eclipse.scout.rt.shared.data.basic.FontSpec.java.patch
Comment 1 Lukas Huser CLA 2011-11-09 06:04:53 EST
Created attachment 206666 [details]
Patch CellStyle: replace m_fontPattern with m_fontSpec
Comment 2 Lukas Huser CLA 2011-11-09 06:05:47 EST
Created attachment 206667 [details]
Patch FontSpec: make FontSpec technically immutable
Comment 3 Andi Bur CLA 2011-12-08 06:17:59 EST
Lukas, thanks a lot for this fantastic bug report, analysis and fix!
Reviewed and applied patches.
Comment 4 Andi Bur CLA 2011-12-23 05:19:28 EST
Bug fix should be applied on 3.7 branch as well.
Comment 5 Andi Bur CLA 2011-12-23 07:22:31 EST
Applied patch on 3.7 branch and changed target milestone to 3.7.2.
Comment 6 Lukas Huser CLA 2012-01-04 08:02:55 EST
Thank you.
Successfully tested on Scout branch 3.7.1. Also, did some quick tests on Scout trunk (3.8).

Performance of displaying data in a table is improved by about a factor of 2.
From our tests:
Table with 33'000 rows: 
- fetching data from server ca. 12 sec
- displaying data in GUI ca. 5 sec (before: ca. 10 sec)
Table with 19'000 rows:
- fetching data from server ca. 7 sec
- displaying data in GUI ca. 3 sec (before: ca. 6 sec)
Comment 7 Matthias Zimmermann CLA 2012-02-29 07:04:26 EST
shipped with eclipse scout 3.7.2 (indigo sr2)