Hi all, Quick follow-up: I tightened up the load test methodology (the first pass was silently capped at 10k rows by an unrelated widget pagination limit that applies to both screenxls and screenxlsx equally, now corrected) and re-ran it with continuous memory sampling, comparing screenxlsx directly against screenxls on the same dataset.
Results hold up well: screenxlsx is 4-11x faster than screenxls at every row count I tested (10k up to 500k rows, and under 5 concurrent users), and uses less peak memory at every tier - including at 500k rows, where screenxls came within about 8% of a 1 GB heap ceiling while screenxlsx had comfortable headroom. Full numbers are on the JIRA ticket (OFBIZ-13567). This confirms screenxlsx handles the volumes screenxls was built for, so I'll go ahead with deprecating screenxls as discussed. Thanks again for flagging this - good to have it properly verified. Regards, Mridul Pathak On Fri, Sep 11, 2026 at 7:05 PM Mridul Pathak <[email protected]> wrote: > Hi Nicolas, > > Following up on this — I ran load tests on the new screenxlsx > implementation to evaluate memory behavior at scale. > > The new implementation is built on Apache POI's streaming extension, > SXSSFWorkbook (rather than the standard in-memory XSSFWorkbook). Because it > flushes rows beyond a small sliding window to temporary storage, it avoids > the heap exhaustion and OOMs traditionally associated with POI. > > In testing up to 500k rows (and across concurrent sessions), heap > consumption remained virtually flat (< 30 MB delta), and 100k rows exported > cleanly in ~5 seconds. > > I have posted the detailed benchmark results, memory profiling metrics, > and comparative analysis directly on the ticket: > https://issues.apache.org/jira/browse/OFBIZ-13567 > > Given these results confirm large-volume streaming is well-handled, we can > safely proceed with retiring the legacy screenxls implementation. > > Regards, > Mridul Pathak > > On Fri, Sep 11, 2026 at 3:28 PM Mridul Pathak <[email protected]> > wrote: > >> Hi Nicolas, >> >> Thanks for providing the context regarding the screenxls implementation. >> I'll load test the new POI based implementation and see if it can address >> high volumes. If not, it definitely makes sense to keep the original >> implementation intact. >> >> Regards, >> Mridul Pathak >> >> On Fri, Sep 11, 2026 at 2:38 PM nicolas.malin.nereide.fr via dev < >> [email protected]> wrote: >> >>> Hello, >>> >>> Thanks for your work on this renderer. It's nice. >>> >>> Just for the screenxls, it was created to support massive export for >>> than 100k lines. The reason that it use macro ftl to open continuous >>> string stream instead of load a java object like Apache POI did. >>> >>> By the past, when I used Apache POI to did that, the lib failed with out >>> of memory due to huge memory consumption. If you implementation fix that >>> it's really good and we can set screenxls as deprecated, otherwise it >>> would be good to keep it and add a description on each case to use >>> screenxls and screenxlsx >>> >>> Nicolas >>> >>> >>> Le 08/09/2026 à 15:04, Mridul Pathak a écrit : >>> > Hi all, >>> > >>> > I've opened two PRs adding a new screenxlsx view-handler type that >>> produces >>> > genuine binary .xlsx workbooks via Apache POI: >>> > https://github.com/apache/ofbiz-framework/pull/1899 for the core >>> mechanism, >>> > andhttps://github.com/apache/ofbiz-plugins/pull/395 wiring it into the >>> > example plugin's demo screens alongside a couple of new UI entry >>> points. >>> > Both PRs are purely additive and don't touch any existing behavior, >>> tracked >>> > as OFBIZ-13567. >>> > >>> > The motivation is that the existing screenxls view-handler type doesn't >>> > actually produce a real Excel file: its FreeMarker macros just emit a >>> plain >>> > HTML table, and it only opens in Excel because Excel is lenient about >>> > mismatched file extensions and content types, while tools like >>> LibreOffice >>> > and Google Sheets are far less forgiving. The new screenxlsx handler >>> builds >>> > a real OOXML workbook directly from the same widget form/grid data, >>> with >>> > typed cells for currency and date fields, and has been verified >>> end-to-end >>> > against a running instance producing files that open cleanly >>> everywhere. >>> > >>> > This makes screenxls obsolete. If there are no objections, I'll file a >>> > follow-up ticket to remove it once OFBIZ-13567 lands. >>> > >>> > Reviews and feedback on the PRs are very welcome. >>> > >>> > Thanks, >>> > Mridul Pathak >>> > >>> >>
