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.

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.

@mgol I've submitted a PR ;-)

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');
        } );
    }
});

@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).

I don't see an easy fix for this. We'd probably have to stop keeping this.bindings as a jQuery object to avoid the repeated uniqueSort invocations, and only wrap it with a jQuery object when needed. But that would break code that relies on the current bindings shape.

BTW, the bindings.add line:

Ideally, bindings should be a Set & classElementsLookup a map to Sets instead of jQuery objects. That does carry a new kind of risk, though, especially for classElementsLookup - whenever a jQuery object is actually needed from them, the Set needs to be converted to a jQuery object which may trigger a slowdown in a different place.

I submitted a draft PR with these changes; it passes tests and the initialization time reported for the test case reported here is at ~50 ms on my machine. I am not sure it won't introduce other issues, though, plus it changes the shape of some objects, so landing it would be risky. Feel free to have a look at the code & test these changes locally, though.

PR: #2313

why is the PR not accepted? I just updated to 1.14.1 today and hit the issue, because I forgot that i had to manually change the code in my previous version to make it load faster.

why is the PR not accepted?

I've explained it above:

"I am not sure it won't introduce other issues, though, plus it changes the shape of some objects, so landing it would be risky. Feel free to have a look at the code & test these changes locally, though."

@patrickteng testing PR #2313 on your project and confirming whether it works fine would help with potentially eventually merging the PR. So far, no one did that, so complaints are unwarranted.

@mgol it worked 2 years back on 1.12.1, and it still is working fine now on 1.14.1 in my project after my change 2 hours ago. But i had to directly modify the js file as it's being used in multiple places.

@patrickteng PR #2313 was opened a few months ago, not 2 years ago. It's physically impossible for you to have applied it on 1.12.1 2 years ago...

@mgol because the issue has existed since forever. This is the same solution that i applied to the latest version.

https://stackoverflow.com/questions/20398400/jquery-ui-sortable-call-is-slow-when-applies-to-thousands-of-elements

I was not asking for the Stack Overflow patch - I was asking about my PR #2313; those are different. The patch may be working for you, but it's using a hack that skips some internal logic which may result in some APIs not working properly - therefore, it's not possible to include it in jQuery UI.

I need people to test my PR on their projects. If no one does that, the likelihood of it being merged diminishes.