Table Performance

Courtney Silva

October 29, 2015 at 5:44 pm #849

How does SPARK provide superior performance?

SPARK Support

October 29, 2015 at 5:48 pm #850

For a simple SPARK Table (backed by Coach NG Human Service data), the entire data set exists in memory (i.e. in the JavaScript VM) by the time a page starts loading. A Table control then must render the table by iterating over each row in memory and creating an HTML representation for each cell in the row. The rendering of a single row has a cost which depends on the rendering cost of each cell in the row. SPARK allows the developer to control how each cell is rendered (as a Coach View or as plain or custom HTML). SPARK Coach Views are much cheaper to render because of their extremely lightweight/no external dependency implementation. Rendering a cell as HTML is usually even cheaper.

IBM BPM Controls have a lot of overhead.  They have to load a bunch of external libraries when being used, and thus there is a lot of overhead.  SPARK controls are not dependent on external libraries, and are thus much cheaper to render.

The SPARK table implementation isn’t part of an external library. It was specifically designed and developed to work with how Coach NG data works – and is therefore optimized for it. For example bi-directional referencing exists between table rows and data records which makes change, append, and delete operations extremely fast. Other optimizations for selection handling, sorting, paging, and filtering exist which are specifically designed to exploit the structure and features of Coach NG data. Thus providing much better performance than a generic table UI component with no such optimizations.

Additionally, the loading of rows in a table can be done asynchronously. Because Javascript is single threaded, the Web browser would normally be “blocked” during the rendering of a table. That blocking behavior – which freezes the UI – can be very disruptive to the user (the freezing behavior is all the more apparent the more costly the rendering of the table). With asynchronous loading, the browser essentially comes up for air between row renders. A UI developer can even configure an async batch size, which tells the browser to only come up for air every N rows – thus allowing the tuning of raw rendering performance in relationship with browser responsiveness.

The SPARK Service Data Table control is designed in a similar way (Table and Service Data Table actually share the same code base), except that it uses AJAX Services to retrieve data instead of relying on a Coach NG Human Service data binding. Server-side paging with the Service Data Table control is also very straightforward since the developer can easily feed the query input data (including for example a page size, an offset, and a sort criteria) to the AJAX service backing the table (through the setQueryData() method) – thus supporting a full server-side paging approach.

Lastly, the appendElement() method of the SPARK Table control can allow true data “streaming” behavior where data can be rendered over time as it becomes available (again without blocking behavior).