Performance issue

[LitoMore]

This library is relatively slow compared to svgpath and svg-path-bbox.

You can use these SVG images below to test the performance:

https://cdn.simpleicons.org/lerna
https://cdn.simpleicons.org/pubg

[thednp]

In what exactly?

[LitoMore]

All of them, like scale, translate, and getPathBBox.

[thednp]

Yea transforms are made by a DOMMatrix shim to allow 3D projections, where svgpath uses a 2D only model, if we were to use that, the performance would be within margin of error.

But as for the pathBBox that totally depends on many things, certainly something to look at in the future. Reminding myself what's what, I implemented a unified segment factory for each path command and that's not the most efficient way to find the pathBBox.

Thanks again for bringing these up.

[thednp]

I'm now working on a performance improvement for getPathBBox to not include pathLengthFactory which basically goes through every sub-pixel possible to determine segment and/or path length. I'm going to implement a similar solution as you suggested.

As for the transform situation it won't change, however with your use case where you combine transform and bbox the performance will be significantly improved.

Should I let you know when I have the new getPathBBox ready for a test?

[thednp]

Yo @LitoMore I've used your HUGE svg file, added some fixes and I've compiled a set of benchmarks, have a look:

I've analyzed the performance issues and made some improvements thanks to you, so I'm giving you a few notes:

• there are 11650 segments in that SVG you linked, that's a lot! 😄
• as you can see the getPathBBox is way faster as well as the initialization
• there was a problem with pathLengthFactory it was always looking for a point at length, even if no distance parameter was given, so that's nicely patched now;
• I've added a sampleSize parameter to all pathLengthFactory related methods, the default is 300 (unchanged), but you can work with 50-100 and still get decent results for another 2-3x performance;
• when SVGPathCommander initializes it will also calculate a shape width and height (via getPathBBox(sampleSize = 20)) to determine a transform origin for the path (an operation that costs about 60ms with your path); subsequent calls of the instance.transform will benefit massively from having an origin already processed and will improve performance further;
• even if we're using a DOMMatrix (with 3D projections), the performance of the transform is still really good don't you think?
• I've updated the wiki with the new changes, hope you can have a look!
• I've also analyzed the tool you linked me (svgpath + svg-path-bbox) and I'll try and implement a similar logic, our pathLengthFactory was doing 3 things at once: calculating length, finding a point at length and finding a min and a max
  for each segment, will have a look at that tomorrow 👍

Have a good one!

[thednp]

Yo @LitoMore, disregard my previous message, watch this:

I've implemented a series of changes that drastically improve both performance and accuracy of A, C and Q segments parsing/processing.

[thednp]

@LitoMore
There could be more performance gains to be achieved by removing the path check for each conversion tool (for instance pathToAbsolute uses isAbsolutePath which really iterates through all segments) but that will be detrimental to the type safety and I don't think this is what we want.

Yes, performance would be on par with SvgPath but is that worth it?

[LitoMore]

You could add a new option to the constructor. Like new SVGPathCommander('M0..', {fastMode: true}) to enable safe mode by default. Or use new SVGPathCommander('M0..', {safeMode: true}) to make the safe mode disabled by default.

The time it takes to process the image is so valuable that I don't mind if it fails because the browser won't throw an exception for a failed SVG image. The situations where I need to constantly check it are so rare that it's not worth it to keep running the check all the time.

[thednp]

Thanks for the suggestion, I'll come back to it as soon as I can.

[thednp]

The type safety is designed to eliminate the possibility of a crash, not just to show the dev some code marked with red in the editor. It might be a case of over checking, but for instance you want to transform a PathArray that is not normalized, something like a RelativeArray, the instance will not return an incomplete or invalid path string, but it will crash because it won't have enough data.

I'm thinking of a way to make the DX better as well, not just improve performance. I'm thinking of two main changes:

• The SVGPathCommander class should have some additional properties like isAbsolute, isRelative, isNormalized
• conversion methods should always receive compatible input values; if however the dev's code crashes, he has the readily available methods (isAbsolutePath, isRelativePath, etc) to perform checks themselves or create a custom logic.

Let's say we do the parsing and preparation faster, but on that 11650 segments path, transform will still take some ms, as explained above, but I think we can give this a try.

[thednp]

Hey @LitoMore how do you like this? (Haven't committed yet)

Transform is still slower, but it does so much more it doesn't matter really for just a couple of milliseconds IMO.

What do you think? Would you like to play?

[LitoMore]

OK, I will try it out tomorrow.