Performance in debug builds

[Johan Nordberg]

Using this library in an application test suite where debug builds are enabled encoding a single 1024x1024 image takes several minutes pegging the cpu (M1) at 100% and using 300mb+ of memory.

Is there some workaround for this? I don't mind png coding being a bit slower in tests but several minutes is a showstopper. I can't seem to find any way to selectively enable optimizations for a swift package included via Xcode's "Package Dependencies" (setting the whole test target to -Os doesn't seem to help either for some reason...)

[taylorswift]

can you share the test image?

have you tried configuring the compression level? keep in mind swift-png uses the highest compression setting by default, which is significantly more aggressive than libpng's maximum setting, so it's not surprising that it's very slow encoding, since it is optimizing for file size, not speed. the higher levels have diminishing returns, so dropping down to say, L5 or so should not severely increase the file size

[Oscar Franco]

I see the same behavior, the PNG I'm using is just a screenshot from my desktop. It only happens on debug build though, on release it seems to be very speedy.

I'm on a m2 air, on Monterrey 12.5

[Philip Johnson]

I wanted to pop in late and say I'm also seeing this in v4.0.2, running on a M2 pro, Ventura 13.0.1.

I am using the compression level 0, which I assume is little to none. Release builds run this very quickly, but debug builds take nearly 2 seconds for a 1280x720 image. Here's what I am doing:

public func writePng(pngData: PNG.Data.Rectangular, to path: URL) throws {
    var pngFile: PngFile = .init(filePath: path)
    try pngData.compress(stream: &pngFile, level: 0)
}

Unfortunately, I am unable to share the images, as they are private. But here is where I'm seeing the CPU usage in the profiler:

[Kelly]

I'm encountering the same issue in 4.0.2/M1/Ventura 13.4.1 with 'normal' sized pngs (~100k, ~1000x1000). Profiling it shows most of the time is spent in the SIMD16 extension find function. Is there any work towards solving this or any suggestions for adjusting that call?