Is there a performant way to update a very, very large workbook using Light Cells? It appears Light Cells is great at reading (handler) and creating from scratch (provider), but you cannot combine the two concepts together to create an update operation on a sheet without pulling it all into memory in the initial load.
Does Aspose offer a manual way of reading an existing sheet row-by-row during the LightCellsDataProvider without loading the entire cells data model?
Aspose.Cells provides the LightCells API, mainly designed to manipulate cell data one by one sequentially without building a complete data model block (using the Cell collection etc.) into memory. It works in an event-driven mode for both reading and writing operations. Moreover, if you are only concerned about memory, Aspose.Cells provides an option e.g., MemorySetting.MemoryPreference for memory performance consideration, so you may try it. Please see the topic for your complete reference on how to optimize memory usage while reading/rendering bigger files having large data sets etc.
Your understanding is correct.
If you find any performance issue with light weight mode or in normal mode, kindly do share a standalone sample console application with template file (if any), zip the project to show the issue, we will check it soon.
Thank you for the quick response, but I don’t think you really answered my question 
I have seen this answer on a lot of your other forum posts and we have used the MemoryPreference setting and it is sub-optimal compared to LightCells.
With Light Cells, how can I update an existing workbook without loading the entire cells data model into memory?
Is there a way of reading the excel sheet row by row during the LightCellsDataProvider to supply load the data model row by row and supply updates based on the provider’s code?
As you may check details and example code in the suggested topic for light cells APIs, when reading template files, the component parses every cell and provides their value one by one, i.e., one Cell object is processed and then discarded, the Workbook object does not hold the collection. In the light weight mode, therefore, memory is saved when importing and exporting Microsoft Excel file that has a large data set which would otherwise use a lot of memory.
Even though the LightCells API processes the cells in the same way for XLSX and XLS files (it does not actually load all cells in memory but processes one cell and then discards it), it saves memory more effectively for XLSX files than XLS files because of the different data models and structures of the two formats.
PwC.Track.Aspose.UpdateCase.zip (4.7 MB)
Please see attached zip file of sample project – cannot updating existing file using the Light Cells Provider and when you use the same workbook object it causes excel to crash
Thanks for the samples.
We will evaluate your sample codes and get back to you soon.
@carl.meyertonspwc,
Currently we cannot support such kind of requirement for LightCells. In fact there were some other users also have the similar requirements and we had made some investigations for this feature. As you know, LightCells works in the event-driven mode to process cells one by one in sequence. For the two processes of reading and writing, they can only work in two different threads. To make them work concurrently and communicate with each other, there are lots of work to do for multiple-threads. It is a complicated task and requires much time for us. We have one ticket(CELLSNET-48548) for this feature, but we are afraid we cannot support it in near future. Anyways, if this feature is implemented, you will get notified here.