AutoSizeColumn became extremely slow after upgrading from npoi 2.6.0 to 2.6.2

[Stoffelche]

we had been stuck for quite a while with npoi 2.6.0 because other package, which depended on Portable.BouncyCastle instead of BouncyCastle.Cryptography. But recently we were able to update to npoi 2.6.2.
But suddenly we experienced an extreme loss of performance in the AutoSizeColumn method. Exports of files with 30000 rows, are now almost impossible taking about 5 minutes, where before it took a few seconds (we did not even bother to measure, because we did not experience AutoSizeColumn as bottleneck). And this with spreadsheets, which don't use formulas and don't use merged cells either.
How can it be, that switching from npoi 2.6.0 which used SixLabors.Fonts in the beta version, to npoi 2.6.2 with SixLabors.Fonts 1.0.0 version causes such a big loss of performance?
Does anybody even know, why this is so?
TIA, Stefan

[Bykiev]

The issue is caused by font loading, it was already fixed by adding font caching in #1179
You can check performance with a master branch

[Stoffelche]

Thank you for you reply. When can we expect to benefit from this fix by a published nuget package. In other words, when will npoi 2.7.0 will be available as nuget package?

[Bykiev]

You can check the milestones of 2.7.0, there are a half of open issues. I don't know the exact release date, but seems not this year

[Stoffelche]

Thanks for pointing this out. And an update 2.6.3 which contains this in my view very important fix is not feasible, either?
I think, updating from 2.6.0 to 2.6.2 and then out of the sudden experiencing such detoriation in existing file exports, certainly would justify a more timely available fix.
We generate excel files for download from web applications, and suddenly users think the download is broken, because suddenly it take many minutes, instead of seconds. And we are blamed for it.

[Bykiev]

Let's wait for @tonyqus, he is a maintainer of this project

[tonyqus]

@Stoffelche I'm the guy making plans for NPOI releases. I'm the project manager and DevOps manager in NPOI project (previously, I'm the major contributor of NPOI). A 2.6.3 release is possible. But I'm still planning and I cannot guaratee anything.

In #1099, someone did raise a hand to ask for increasing the frequency of releases. But I have to tradeoff because each release usually takes me one week to finish everything. It's a standard release process like a software company

It includes the following tasks

• Summarize release note for the release (example: NPOI 2.6.2 Release Notes #1168)
• Test case verifications(about 4000 unit tests) and some regression bug fixes
• Release candidate (RC) nuget pakcage test (Sometimes, the nuget package may miss something or not working at all)
• A release annoncement and perhaps a post to thank all the contributors ( example post)

You have to understand NPOI is still a hobby project instead of commercial although it looks like a commercial one. I have to control the contribution time I put on this project per month because I got very little donation (less than 400 USD per year). To be honest, my family member did have big concern on this project because of very little profits.

As a tradeoff, the current release frequency is 3-4 month (which means 3-4 releases a year). That's maximum release frequency I can provide for now. NPOI 2.6.2 release happened just less than 2 month ago (on Sep 11). In other words, the next release may happen in Dec, 2023.

[tonyqus]

@Stoffelche And as a workaround, I do suggest you use predict fixed width for columns instead of calling AutosizeColumn. Automatic column width adjustment is a nice-to-have feature but it does consume CPU and performance. It has no impact on data in the Excel. I guess if you turn AutosizeColumn off, your users will not complain a lot.

[Stoffelche]

Thanks for pointing this out. I generally understand your point.
The only thing is, in this particular situation, there is a deterioration of an existing functioning feature, by orders of magnitude, rendering it practically unusable, where it was working before, thus breaking the code of applications, that already had used it, because it was working before.
Therefore I think it would merit kind of a hotfix or at least being included in a timely minor release follow-up.

[Stoffelche]

As to your suggested workaround, it is kind of not feasible in a situation where many excel files are generated with different contents.
My workaround is to do the AutoSizeColumn after 500 rows were inserted, and then proceed with filling up.
I can live with this workaround for now, so don't bother.
Only, I still think, this should not happen, as it breaks existing working applications.

[Bykiev]

Only, I still think, this should not happen, as it breaks existing working applications.

I believe you should test your app before publishing in production...

[tonyqus]

Fixed by #1179