Performance issue in sortable widget with long lists

[stollr]

There is a huge performance issue in the sortable widget which started in version (1.12.1) and is still existing in current version 1.13.1, when used with large lists.

There's already a ticket for this issue in the old tracker: https://bugs.jqueryui.com/ticket/15097 and a corresponding stackoverflow question.

Today I have created some new fiddles to show the issue. Please compare the console output in the fiddle:

jquery-ui version	fiddle url	output	time of initialization in seconds
1.11.4	https://jsfiddle.net/m0j61Lnw/0/	"#1", "Mon Mar 28 2022 12:24:40 GMT+0200 (Mitteleuropäische Sommerzeit)"	0
		"#2", "Mon Mar 28 2022 12:24:40 GMT+0200 (Mitteleuropäische Sommerzeit)"
1.12.0	https://jsfiddle.net/m0j61Lnw/2/	"#1", "Mon Mar 28 2022 12:15:08 GMT+0200 (Mitteleuropäische Sommerzeit)"	2
		"#2", "Mon Mar 28 2022 12:15:10 GMT+0200 (Mitteleuropäische Sommerzeit)"
1.12.1	https://jsfiddle.net/m0j61Lnw/3/	"#1", "Mon Mar 28 2022 12:15:46 GMT+0200 (Mitteleuropäische Sommerzeit)"	16
		"#2", "Mon Mar 28 2022 12:16:02 GMT+0200 (Mitteleuropäische Sommerzeit)"
1.13.1	https://jsfiddle.net/m0j61Lnw/1/	"#1", "Mon Mar 28 2022 12:23:11 GMT+0200 (Mitteleuropäische Sommerzeit)"	16
		"#2", "Mon Mar 28 2022 12:23:27 GMT+0200 (Mitteleuropäische Sommerzeit)"

There are some solutions suggested in the stackoverflow answeres and in the old ticket.

It would be great if you could fix the issue. Otherwise we are stuck on version 1.11.4 :-(

[stollr]

Update:
I can approve that this workaround significantly reduces the performance issue:

$.ui.sortable.prototype._setHandleClassName = function() {
    this._removeClass( this.element.find( ".ui-sortable-handle" ), "ui-sortable-handle" );
    $.each( this.items, function() {
        (this.instance.options.handle
         ? this.item.find( this.instance.options.handle )
         : this.item
        ).addClass('ui-sortable-handle');
    });
};

If set before the initialization of the sortable.

[mgol]

Thanks for the report. Since the issue is already in 1.12, given limited team resources it's not likely to be fixed by the UI team; see the project status at https://blog.jqueryui.com/2021/10/jquery-maintainers-update-and-transition-jquery-ui-as-part-of-overall-modernization-efforts/. I'd review a PR if you'd like to submit one, though.

[stollr]

@mgol I've submitted a PR ;-)

[melloware]

I can confirm for the last 5 years in Primefaces we have used this same patch.

Here is the original report ticket: primefaces/primefaces#3675

// GitHub PrimeFaces #3675 performance
$.widget( "ui.sortable", $.ui.sortable, {
    _setHandleClassName: function() {
        this._removeClass( this.element.find( ".ui-sortable-handle" ), "ui-sortable-handle" );
        $.each( this.items, function() {
                        (this.instance.options.handle 
                        ? this.item.find( this.instance.options.handle ) 
                        : this.item
                        ).addClass('ui-sortable-handle');
        } );
    }
});

[dahopem]

@mgol, @fnagel, the cause for the excessive time complexity is an O(n*n*log(n)) algorithm.

Analysis

Consider this call stack:

. _setHandleClassName (loops over all items)
. _addClass
. _toggleClass
. _classes
. processClassString
. bindRemoveEvent
. _on
. add
. jQuery.uniqueSort (loops over all items)

Given that the jQuery.uniqueSort will have a time complexity in O(n*log(n)), _setHandleClassName will have a time complexity in O(n*n*log(n)). This more than quadratic time complexity makes _setHandleClassName inacceptably slow for large inputs (e.g. 5000 items which shall be sortable).