SelectOneMenu: Options to improve client side (browser) render performance?

[stolp]

Hello,

I am using Primefaces 8.0RC2, but the same applied to Primefaces 7.10:

In my application I have several p:datatable pages containing 1 to 3 columns with p:selectOneMenu entries.
For larger numbers of rows I experience a severe slowdown once the browser tries to render the page.
To give an impression, a page of 200 table rows each containing three p:selectOneMenu elements renders in ca. 3 seconds on a really fast desktop machine.

I already tried to convert columns to a p:cellEditor as well as using dynamic="true" in the selectOneMenu, but both showed no sign on improving the situation.

I am aware of viewtopic.php?t=46444 but I don't know if new solutions have been found since then.

Reverting to h:selectOneMenu is not an option I like to see here, although it does indeed improve performance tremendously.

Are there other options I am missing to get a decent performance?

[tandraschko]

I think the only way is to profile the JS code and/or optimize the dynamic=true; feel free to work on it

[stolp]

I recorded a profiling from the list page rendering described above: https://www.file-upload.net/download-13 ... r.png.html.

Page rendering seems to have a bottleneck in filtering of the initialization code (first part). I have no idea about why renderDeferred() is showing up at second place.

Being mostly JavaScript illiterate, I am unsure on how to proceed from here. Any further input is welcome.

[tandraschko]

I would try to get the code and e.g. comment code and try again.
Like e.g. remove the whole init of the overlay panel, which should not be rendered when dynamic=true

[stolp]

I gave it another go against 8.0-SNAPSHOT as of today. Results are here: https://www.file-upload.net/download-13 ... .png.html

I think I can now pinpoint at least the second problem bottleneck, it is in the implementation of getAppendTo():

Code: Select all

    getAppendTo: function() {
        var dialog = this.jq.closest('.ui-dialog');

        if(dialog.length == 1) {
            //set position as fixed to scroll with dialog
            if(dialog.css('position') === 'fixed') {
                this.panel.css('position', 'fixed');
            }

            //append to body if not already appended by user choice
            if(!this.panel.parent().is(document.body)) {
                return "@(body)";
            }
        }

        return this.cfg.appendTo;
    },

Code: Select all

var dialog = this.jq.closest('.ui-dialog');

is the performance killer here. Does this code really belong here and Is it necessary to always check for fixed positions even when appendTo is not set as a configuration option?

For problem #1 I am unsure, is this the visible check in DeferredWidget?

Code: Select all

    PrimeFaces.widget.DeferredWidget = PrimeFaces.widget.BaseWidget.extend({

        renderDeferred: function() {
            if(this.jq.is(':visible')) {
                this._render();
                this.postRender();
            }
            else {
                var container = this.jq.closest('.ui-hidden-container'),
                $this = this;

                if(container.length) {
                    this.addDeferredRender(this.id, container, function() {
                        return $this.render();
                    });
                }
            }
        },

If yes, why is it so expensive?

[kukeltje]

Code: Select all

var dialog = this.jq.closest('.ui-dialog');

is the performance killer here. Does this code really belong here and Is it necessary to always check for fixed positions even when appendTo is not set as a configuration option?

It might be needed implicitly for (modal) dialogs (on the other hand, I would have expected it too for other overlays but on the other other hand it might still be a problem there )

Maybe some way of caching the result on a closer container (the datatable and the likes) and try to find it there might improve things a lot.

[tandraschko]

1) i optimized the closest to use JS native, it hsould be much faster now
2) not sure; :visible is not that fast: https://stackoverflow.com/questions/469 ... ry-visible

[tandraschko]

ignore this comment

[kukeltje]

it 'feels' this breaks things that now (with a performance penalty) just work. Or is the appendTo by default empty and by now explicitly setting it to `@(body)` the looking up of the dialog is skipped? Would make a good (important) migration note.

[stolp]

Thanks for the quick fix!

This actually helps a lot, saving about 25% of the script execution time.

I did some performance tests without dynamic content: https://www.file-upload.net/download-13 ... 4.png.html

And with dynamic content: https://www.file-upload.net/download-13 ... 4.png.html

I dare say that this has no relevant influence in this use case (SelectOneMenu is inside a p:cellEditor so this is expected).

There is still one significant hotspot regarding an onsuccess hook left, I currently have no idea where this is rooted. Hints are welcome.