We had similar problem when the input xlsx had data validation set to the whole column (with few first rows excluded). When limiting it to the first few hundred rows (something like rows 3-500), the issue disappeared.

For data with around 3000 rows, 13 rows, exceljs could generate Excel fast.
I have data table with more than 500+ columns, 12000 rows. I have been waiting for >15mins, but no Excel was generated. This is a big minus. However, the package csv-stringify takes around 4 seconds to complete the generation of a CSV report of the same data.

Same to me, Write file 700kb 4K+ row used 2s on m1 and 9s on server

I was running into a problem like this on a 49kb file where it wouldn't finish loading in even after literally days. I did a deep dive into this and this is what I found.

When loading in a file with data validations applied to ranges of cells, it enumerates the address of each individual cell which the validation applies to and stores that (see https://github.com/exceljs/exceljs/blob/master/lib/xlsx/xform/sheet/data-validations-xform.js#L218). This goes relatively quickly (a little less than a millisecond per address on my machine) until it hits 8,388,607 total cell addresses across all validations, at which point it immediately slows WAY down (~3 seconds per address on my machine). As it happened my small spreadsheet had a lot of data validations applied to large ranges (well past what actually existed in the spreadsheet yet).

Here's the odd thing though, exceljs completely supports data validations by ranges (see #1109 (comment)). I ended up pulling a really screwy workaround where I pre-parsed the spreadsheet using JSZip and xmldom to remove data validations from the sheet xml files, loaded the spreadsheet with exceljs, and then added the data validations back in by their original ranges and that worked. It seems like it should be possible to change the loading logic to just use the ranges though and skip the cell address enumeration.

I just ran into the same thing with a weird (but non-malicious) spreadsheet that got uploaded to a service I'm working on.

Somehow it ended up containing this crazy data validation:

<dataValidation type="list" allowBlank="1" showInputMessage="1" showErrorMessage="1" sqref="F1583:F1048576 G1583:I1048576 Q1583:Q1048576 U1583:AB1048576 S1583:S1048576 L1583:L1048576 AD1583:AE1048576"><formula1>#REF!</formula1></dataValidation>

... which then makes exceljs loop over 17,798,898 cells and set a hash key for each(!)

I came up with this super hacky workaround to turn Range#forEachAddress into a noop:

require('exceljs/lib/doc/range').prototype.forEachAddress = function () {};

It would be nice to avoid that. In my application I don't really need these data validations to be applied, so it would be great if they could be turned off. Alternatively we could use the existing maxCols / maxRows to intersect the ranges with the supported data area.

any updates on this?

I've just run into this exact issue too.

My 2c is that it seems Google Sheets cuts off these data ranges with 1048576 rows (the maximum that Excel supports btw) at 1000 rows.

My "fix" for this is to limit the aforementioned forEachAddress method on the Range class to 1000 rows as follows. Had to fork to achieve this.

forEachAddress(cb) {
    for (let col = this.left; col <= this.right; col++) {
      for (let row = this.top; row <= Math.min(this.bottom, 1000); row++) {
        cb(colCache.encodeAddress(row, col), row, col);
      }
    }
 }

Maybe a contributor that knows more might be able to limit it to the actual number or rows that have data in them if that exists?