fritzing-app
fritzing-app copied to clipboard
fritzing
Reduce load times on part bins and any svg processing
One of the more annoying aspects of fritzing is the initial load of parts bins when you scroll through them with your mouse wheel. Thus I decided to start looking through the code to improve the speed of this initial parts bin load (IPBL?). Through the use of linux perf tools I was able to track it down to a series of naive svg processing routines within TextUtils. The SVG DOM was being constructed, modified, converted to string, and then destroyed over and over. According to perf, this took up between 3 and 8 percent of the overall program's execution (well QDomDocument.setContent and QDomDocument.toString are the actual expensive operations). Thus I have changed fixMuch and fixPixelDimensionsIn to be more componentized so I can use the internals without having to construct a new DOM every single time. I can instead just pass an already created DOM in and modify it. I was able to confirm that this is safe because the string representation of the SVG is saved after the main load is performed as well. Loading bins feels very very fast now and I can scroll with the mouse wheel without getting annoyed. Even searches feel faster now.
I also cleaned up PaletteModel::loadPart so that it is easier to maintain via the use of a static map for pureEqualityChecks and lambdas. New classes of major parts should be much easier to install into the loadPart class without fear of breakage.
In addition to these fixes, I also did my usual nullptr check fixes and ctor cleanups.
Hi, I have created issue #3589 for this.
Are you sure compiler optimization settings are correct with the build you are using? Performance problems when scrolling are not really on top on the reported problems so far.
That said, I also experimented with some speedups. I am also evaluating to use resvg / usvg instead of QtSvg, we we get a much more svg standard compliant rendering (reduces issues with inkscape and illustrator created files)
Would you be fine with cherry-picking the nullptr changes and similar to the "cleanup" branch?
No worries, I'll pull the nullptr checks out. If you're planning to redo how the svgs are processed then I am all for it. There is a lot of string manipulation by Fritzing going on to reach compliance as it stands. Are you talking about the rust svg library resvg?
Oh and to answer your question about optimization level, I was testing with the Debug build. I like doing that because if I can make the debug build run faster then the release build (usually) will have performance improvements as well. One thing I did not mention was that the parts bin I was using for testing was the entire adafruit parts bin, it can take some time to load on initial selection. I also found that searching seems to run much faster too but that is probably subjective.
If you're going to use this rust library (glad it has a C-API) then is the plan to require a rust compiler as well?
I can chime in and say that the parts load time is poor. Initial startup is slow and switching to a different parts bin is also time consuming.
