Improve batched Column performance by mvilliger · Pull Request #2260 · eclipse-scout/scout.rt

mvilliger · 2026-07-17T09:18:35Z

SmartColumns with batched LookupCall already collected all keys and then updated the cell text as soon as the async LookupCall completed. Therefore, there is only one promise for the LookupCall execution returning the texts for all keys.
Unfortunately the SmartColumn then splits this promise into one promise for each cell containing only the value for the specific cell. This leads to thousands of promises on large tables.
These promises are collected in the TableUpdateBuffer and removed as they resolve. This operation was O(n^2) as the buffer internally used an array to store the promises.

Processing lots of such promises together with the inefficient handling of the buffer leads to unnecessary computation time on the client. Because of some async overhead, executing a promise for each cell is significantly slower than executing one promise handling all cells. On large tables with thousands of rows and multiple SmartColumns this may sum up to several seconds just to process these promises.

This commit changes the following:

Introduce a helper class BatchCall to collect keys and using an async batch callback executed for all the keys.
Column uses this new BatchCall in formatValue() if available. This allows each column to support batch processing more easily. Implementors only need to set the _batchFormat member defining the batch callback.
The deferred Cell text update in batch mode always updates all texts of the column instead of only one cell. Accordingly, _formatValue and formatValue() in the async case now return all texts instead of only the one for a single cell.
StaticLookupCall & LookupCallColumn now supports batching to benefit from the new features.

410165, 399939

fschinkel · 2026-07-30T15:01:59Z

+  }
+
+  protected _serializeKey(key: TKey): string {
+    return dataObjects.stringify(key);


Maybe deserialize the key first. Consider a SmartColumn<SomeDo> using the RestLookupCall to lookup its values. Depending on whether SomeDo is a BaseDoEntity and/or how the data of the table is loaded the value of the cell might be a BaseDoEntity. But as the resulting key of the RestLookupCall will always be a pojo simply using dataObjects.stringify will result in different values if the pojo has e.g. a _typeVersion set.

fschinkel · 2026-07-31T15:57:02Z

+  }
+
+  protected _batchFormatValues(keys: TValue[][]): JQuery.Promise<Map<TValue[], string>> {
+    const allKeys = [...new Set(keys.flat())];


Does this work for complex objects?

Should be ok, because key-identity is handled by BatchCall. Correct?

bschwarzent · 2026-08-17T06:28:25Z

    this._tableColumnsChangedHandler = this._onTableColumnsChanged.bind(this);
    this._realWidth = null;
-
+    this._batchFormat = null;


Initialization to null not necessary for this internal property (or can be merged with the property declaration).

bschwarzent · 2026-08-17T06:30:25Z

      // If every cell of a row is empty the row would collapse, using nbsp makes sure the row is as height as the others even if it is empty
      content = '&nbsp;';
      cssClass = strings.join(' ', cssClass, 'empty');
+    } else if (cell.flowsLeft) {


Event shorter:

} else { content = cell.flowsLeft ? text + icon : icon + text; }

bschwarzent · 2026-08-17T06:32:48Z

-      });
-
+  setCellTextDeferred(promise: JQuery.Promise<BatchCallResult<TValue, unknown>>) {
    // (then) promises always resolve asynchronously which means the text will always be set later after row is initialized and will generate an update row event.


What does (then) at the start of this sentence mean?

bschwarzent · 2026-08-17T06:35:16Z

+      this._batchFormat.addKey(value);
+      return this._batchFormat.promise();
+    }
    return scout.nvl(value, '');


If value is not a string, the result will also not be a string, which contradicts the declared return type of this method. Maybe just convert it to String, same as in _batchFormatResultToCellText()?

bschwarzent · 2026-08-17T06:41:21Z

+      return;
+    }
+
+    promise


Since we are not returning the result, it should be safe to use then/catch instead of done/fail.

bschwarzent · 2026-08-17T08:48:32Z


+  protected _batchFormatValues(keys: TValue[]): JQuery.Promise<Map<TValue, string>> {
+    const lookupCall = this.lookupCall.cloneForKeys(keys);
+    this.trigger('prepareLookupCall', {lookupCall});


The previous implementation in _formatValue() triggered this event including the row property. Because we are now in a batch context, this can no longer be set. However, listeners still may rely on the property. Isn't this a problem?

bschwarzent · 2026-08-17T08:49:53Z

+ *
+ * SPDX-License-Identifier: EPL-2.0
+ */
+import {scout} from '../scout';


Import from index, not from individual files.

bschwarzent · 2026-08-17T08:58:11Z

+    if (arrays.empty(keys)) {
+      return $.resolvedPromise();
+    }
+


Suggested change

bschwarzent · 2026-08-17T09:05:32Z

+import {dataObjects} from '../dataobject/dataObjects';
+import $ from 'jquery';
+
+export class BatchCall<TKey, TValue> {


Add some documentation? (see old BatchLookup implementation).

bschwarzent · 2026-08-17T09:07:50Z

+  }
+
+  /**
+   * Same key might point to the same values! Do not modify (read only!)


What is the purpose of this documentation? It does not seem to be related to this method. Modifying the content of keys is never a good idea, is an explicit warning really needed?

SmartColumns with batched LookupCall already collected all keys and then updated the cell text as soon as the async LookupCall completed. Therefore, there is only one promise for the LookupCall execution returning the texts for all keys. Unfortunately the SmartColumn then splits this promise into one promise for each cell containing only the value for the specific cell. This leads to thousands of promises on large tables. These promises are collected in the TableUpdateBuffer and removed as they resolve. This operation was O(n^2) as the buffer internally used an array to store the promises. Processing lots of such promises together with the inefficient handling of the buffer leads to unnecessary computation time on the client. Because of some async overhead, executing a promise for each cell is significantly slower than executing one promise handling all cells. On large tables with thousands of rows and multiple SmartColumns this may sum up to several seconds just to process these promises. This commit changes the following: - Introduce a helper class BatchCall to collect keys and using an async batch callback executed for all the keys. - Column uses this new BatchCall in formatValue() if available. This allows each column to support batch processing more easily. Implementors only need to set the _batchFormat member defining the batch callback. - The deferred Cell text update in batch mode always updates all texts of the column instead of only one cell. Accordingly, _formatValue and formatValue() in the async case now return all texts instead of only the one for a single cell. - StaticLookupCall & LookupCallColumn now supports batching to benefit from the new features. 410165, 399939

fschinkel force-pushed the features/mvi/26.2/smartColumnPerformance branch from e33f8c3 to 68ba14a Compare July 30, 2026 14:10

fschinkel reviewed Jul 30, 2026

View reviewed changes

fschinkel requested changes Jul 30, 2026

View reviewed changes

mvilliger force-pushed the features/mvi/26.2/smartColumnPerformance branch 2 times, most recently from d96b915 to ab8eef4 Compare August 10, 2026 11:35

fschinkel force-pushed the features/mvi/26.2/smartColumnPerformance branch from ab8eef4 to 05fbb7a Compare August 11, 2026 15:29

fschinkel reviewed Aug 11, 2026

View reviewed changes

bschwarzent reviewed Aug 17, 2026

View reviewed changes

mvilliger force-pushed the features/mvi/26.2/smartColumnPerformance branch 4 times, most recently from 0b5fbb1 to 16eff29 Compare August 20, 2026 14:11

mvilliger force-pushed the features/mvi/26.2/smartColumnPerformance branch from 16eff29 to de239fe Compare August 31, 2026 11:23

mvilliger force-pushed the features/mvi/26.2/smartColumnPerformance branch from de239fe to 3ae3ebf Compare September 2, 2026 09:12

Navigation Menu

Uh oh!

Improve batched Column performance - #2260

Improve batched Column performance#2260
mvilliger wants to merge 1 commit into
releases/26.2from
features/mvi/26.2/smartColumnPerformance

mvilliger commented Jul 17, 2026

Uh oh!

fschinkel Jul 30, 2026 •

edited

Loading

Uh oh!

fschinkel Jul 31, 2026

Uh oh!

bschwarzent Aug 17, 2026

Uh oh!

bschwarzent Aug 17, 2026

Uh oh!

bschwarzent Aug 17, 2026

Uh oh!

bschwarzent Aug 17, 2026

Uh oh!

bschwarzent Aug 17, 2026

Uh oh!

bschwarzent Aug 17, 2026

Uh oh!

bschwarzent Aug 17, 2026

Uh oh!

bschwarzent Aug 17, 2026

Uh oh!

bschwarzent Aug 17, 2026

Uh oh!

bschwarzent Aug 17, 2026

Uh oh!

bschwarzent Aug 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

+                    return;
+                  }
+                  promise

Uh oh!

Conversation

mvilliger commented Jul 17, 2026

Uh oh!

fschinkel Jul 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

fschinkel Jul 30, 2026 •

edited

Loading