Hey, I really love your mod. But since recently, since you updated it to 2.x it's very, very slow to load with my previous settings. I know that width/height limits of 256 each are significantly higher than the default but the older version of your mod worked perfectly well with these numbers.

I would be fine with Merge Chests taking a little longer to load. But the weird thing is that any subsequently loaded mod also suddenly takes far longer to load depending on the settings of Merging Chests.

I wonder if you could add some mechanism that makes the game generate the needed sprites for the merged chests on demand and not for each and every possible combination during load.

Previously the count of generated chest was linear with settings of max length. Now with area chests the count increases quadratically. Previously the game generated 512 chests, now (unless you modified default area settings) it generates has to generate more than 65000. I don't think so it's possible to do some delayed loading. Unless you're using 256x6 chest I'd suggest to limit max chest area.

I might implement setting where you enumerate chests you want on top of normally generated using max width/height/area.

Same here. Too high limits can eat all existing RAM

Did you use default chest size limits?

I'm not sure if Factorio supports sprite atlases for entities. It might be an option to generate exactly 9 different tiles: 4 (tl, tr, bl, br) for the corners, 4 (t, l, b, r) for the edges and one for the center. That way any size of chest would be possible without any additional sprite generation. For chests < 3x3 just skip the edge sprites along the sides shorter than 3 and the center sprites, for chests > 3x3 just repeat the edge and center sprites.

Or alternatively how about generating the needed chest sprites in the game on demand?

That is exactly how the chest sprites are generated. This mod has 7 pictures segmented to be able to make sprite for any size needed. The problem is that game requires definition of sprites of all entities at startup. So for every 'tile' in chest there is 1 (or two if this tile also have its shadow) tile definition.

Now if you unleash the mod to generate for example all chests up to 1000x1000 the biggest chest will cover 1 milion tiles so it will have 1 milion of these definitions. And the second largest will have 999 thousand of them. Every single tile definition is very small (a couple of tens of bytes probably). That means maybe 100MB just for these two largest chests. And now the mod still have to generate 999998 more of them.

Approximation for total memory usage is: "20 x N x N x M x M" bytes, where N is max width and M is maximum height. Couple of examples of memory usages if max width and height is set to same number:
N=42 (default) => 62MB
N=100 => 2GB
N=256 => 85GB
N=1000 => 20TB

One way to reduce the number of sprite definitions would be to have additional sprites for filling the edges and the center area that cover 2^N tiles in one direction (or two in case of center). That way, you have logarithmic growth of sprite definition data - instead of quadratic. That should also reduce the load on the engine ingame (Factorio is build for high sprite counts though, so the impact might be too small to notice).

That said: Regardless of sprite definition overhead, chests covering hundreds of thousands of tiles look like a pretty bad idea anyway. I actually used the mod for creating one-dimensional chests of lengths up to 6 tiles at load/unload stations and felt like cheating already...

This basically was how this mod started, I created a program which generated sprites for one dimentional chests of length up to 42, because game doesn't allow sprites larger than 2048x2048 pixels (if I remember correctly). You can still download 1.1.0 version to see the large sprite used.

There was a idea to create multi tile decals to break the monotonicity of the sprite by for example have large hole in a warehouse roof. This would reduce memory imprint (barely noticable) and look cooler (main focus of this change) at expense of generation complexity. I didn't implement this because I lost the artist which was creating the sprites for me.