<div dir="ltr"><div dir="ltr"><div>Partly inspired by issue</div><div> <a href="https://bugs.freepascal.org/view.php?id=37706" target="_blank">https://bugs.freepascal.org/view.php?id=37706</a></div><div>I profiled Lazarus code with Valgrind to find what could cause such a slowdown in form designer.</div><div>I didn't see any serious slowdown myself but clearly the designer eats more resources than it should.</div><div>Registered components were searched all the time by class name. I changed the cache to use class type instead. It actually simplified and sped up things. It is function TBaseComponentPalette.FindRegComponent (was FindComponent) which is called also when mouse moves over the designer.</div><div>The biggest change is in r64182.</div><div>In r64184 I changed more code to use the component class type cache. By surprise it caused extreme slowdown. Selecting a component in designer took > 5 seconds with QT5 bindings, but the CPU was not under load. In addition with GTK2 bindings the selection dots didn't show.</div><div>All that was gone after a clean build!</div><div>What could cause it? I have no idea. A Sleep() call or Thread.WaitFor could cause a delay without CPU load but the code had neither.</div><div>Anyway please test with the latest changes. Build clean if you need to.</div><div><br></div><div>I want to optimize function TPkgManager.GetUnitsAndDepsForComps.</div><div>It is part of Sven Barth's recent addition. </div><div>It has 2 nested for-loops. The inner is :</div><div>    for CurUnitIdx:=0 to CurUnitNames.Count-1 do</div><div>just after an item is added to CurUnitNames. Maybe the loops should go after each other instead of being nested. Now it may indeed be slow with a densely populated form.</div><div>Comments?</div><div><br></div><div>Regards,</div><div>Juha</div><div><br></div></div></div>