Thank you so much for your feedback! After profiling the app a bit, it
looks like the top hotspot is in
org.apache.xmleans.impl.values.XmlObjectBase.monitor. It's locking access
for most cell ops e.g.:
public final void setBigDecimalValue(BigDecimal obj) {
if (obj == null) {
this.setNil();
} else {
synchronized(this.monitor()) {
this.set_prepare();
this.set_BigDecimal(obj);
this.set_commit();
}
}
}
It's basically hogs execution the most. Wonder what's the best way to try
fixing it? Replace the abstract class with custom non-synchronized
implementation?
On Sat, May 21, 2022 at 6:03 AM Andreas Reichel <
[email protected]> wrote:
> One more thing: Swapping/Paging!
>
> The least thing you need to ensure is that you have enough RAM to hold
> your 10 WorkSheets in memory without paging/swapping involved.
> Depending on your workbook, that can be huge memory!
>
> As soon as swapping/paging kicks in, any performance measurement is
> useless because IO will be the bottleneck and dominate your tests.
>
> On Unix/Linux, engage VMSTAT and ensure, there is no SO/SI shown during
> your test.
>
> Good luck
> Andreas
>
