id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
5952	Scaling of matching and sorting for simulation badly deteriorated from v.1.15	Francesco Casella	Karim Adbdelhak	"The scalability of the backend was greatly improved starting from v.1.9. About three years ago, when 1.12 was released, most serious issues were solved, and a few corner cases remained, which are collected in #4146. I since then stopped watching those results frequently, but I now realize that was a mistake :)

I am convinced that spending more resources to streamline the scalarized backend further would not be a good idea, and we should rather try to get ASAP to an efficient vectorized backend and code generation framework, which will be way more efficient, see #5917. However, we need to avoid regressions. 

Let me focus on a specific model of the ScalableTestSuite, {{{Electrical.DistributionSystemAC.ScaledExperiments.DistributionSystemLinearIndividual_N_XX_M_XX}}}

If you check the [https://libraries.openmodelica.org/branches/newInst/ScalableTestSuite_noopt/ScalableTestSuite_noopt.html newInst master branch report], and look for the time spent by matching and sorting, you find the following results

||=N=||=M=||=Time||
||10||10||2.7||
||14||14||9.3||
||20||20||41.6||
||28||28||163||

This is bad, matching and sorting in this case used to scale up much better. In fact, we can see that easily via the [https://libraries.openmodelica.org/branches/overview-combined.html cross-version report], scroll down to {{{ScalableTestSuite_noopt}}}. The time spent by matching and sorting for the N_28_M_28 case are reported here for your convenicence

||=ver=||=Simulation=||=Initialization=||
||1.12||0.40||0.49||
||1.13||0.43||2.95||
||1.14||0.43||0.48||
||1.15||2.53||0.47||
||master||150||0.50||

What is interesting is that the time to perform matching and sorting for the simulation problem went through the roof with some commits on the 1.16.0-dev master branch, some of which were apparently back-ported to 1.15 as well, while the time to perform it for the initialization problem (which is a superset of the former) remained the same.

I guess some of the improvements related to tearing, state selection, MSSS, and the like accidentally introduced some operation that improperly scales with O(N^2^). Sometimes something as trivial as traversing a tree or a list in the wrong direction can lead to that. With small models, it doesn't make any difference, but as the size grows, this single operation will eventually dominate the time spent by the backend, if all other steps grow with a lower exponent. 

@Karim, @AnHeuermann, would you mind having a look? You know what has been done there, so it's probably fairly easy for you to figure out what are the bad commits.

This is a rather bad regression, we should fix it ASAP and also back-port it to 1.15, since that was already somewhat affected, though not that badly.

Please consider the recommendations written in #4362 every time you push some code to the master branch. We currently do not have any automatic check against even serious scaling performance degradations, these must be checked manually by inspecting the reports of the larger testsuite. Maybe you don't need to do it every time, but it would be good to compare the ScalableTestSuite reports with the master branch and with the latest stable release every now and then, to check for significant regressions on larger models.
 "	defect	closed	blocker	1.16.0	Backend		fixed		Andreas Heuermann Lennart Ochel tobias.krenz@… Martin Sjölund