Hi @Amjad_Sahi,
The XLSB parsing performance of 19.8.6 is much better, good work
In some of our test cases, the performance is close to double of 19.8.0.
That said, in performance profile data of 19.8.6, I still observe a fair amount of CPU being spent on compression. In one of my tests it’s around ~7% now, which is much better than the ~22% observed using 19.8.0.
The remaining call path I see with the profiler is:
main Runnable CPU usage on sample: 968ms
java.util.zip.Deflater.deflateBytes(long, byte[], int, int, int) Deflater.java (native)
java.util.zip.Deflater.deflate(byte[], int, int, int) Deflater.java:444
java.util.zip.Deflater.deflate(byte[], int, int) Deflater.java:366
java.util.zip.DeflaterOutputStream.deflate() DeflaterOutputStream.java:251
java.util.zip.DeflaterOutputStream.write(byte[], int, int) DeflaterOutputStream.java:211
java.util.zip.ZipOutputStream.write(byte[], int, int) ZipOutputStream.java:331
com.aspose.cells.a.f.zk.write(byte[], int, int)
com.aspose.cells.a.c.zab.a(zm, zm)
com.aspose.cells.zrz.a(HashMap)
com.aspose.cells.zapn.a(Workbook, LoadOptions, boolean)
com.aspose.cells.zjp.a(zm)
com.aspose.cells.zjp.a(String, zm, LoadOptions)
com.aspose.cells.Workbook.a(String, LoadOptions)
com.aspose.cells.Workbook.<init>(String)
It would be interesting to know what is the background of this remaining CPU hotspot, and it we can somehow prevent it, for example, by indicating that we are opening the workbook for reading only, and do not require the functionality to save it later.
Kind regards,
Taras