We have an issue regarding the IgxExcelCoreModule's speed in our project. For our purposes, we need to read in the names of each sheet within the workbook and then the headers of each sheet. The following code is what we used to achieve that functionality:
if (event.target.files.length > 0) { this.importFile = event.target.files[0]; //// Infragistics this.headersByWorksheetList = []; this.availableWorksheetList = []; Workbook.load(this.importFile, null, (workbook) => { console.log("load") // Access the worksheets for (let i = 0; i < workbook.worksheets().count; i++) { const worksheet = workbook.worksheets(i); this.availableWorksheetList.push(worksheet.name); const headers = []; const firstRow = worksheet.rows(0); for (let cellIndex = 0; cellIndex < firstRow.cells().count; cellIndex++) { headers.push(firstRow.cells(cellIndex).value) } this.headersByWorksheetList.push(new HeadersByWorkSheet(worksheet.name, headers)); // console.log(`Worksheet ${i + 1}: ${worksheet.name}`); } console.log(this.headersByWorksheetList); }, (error) => { // Error callback: Handle any errors console.error('Error loading workbook:', error); }); }
However, doing this with a reasonably small workbook (1700KB) takes ten plus seconds to load and with a larger one (21MB) it took around 4-5 mins, which is something we would potentially need to do. This seems very unwieldy considering the simplicity of the functionality required. And this is just to get a response from the Workbook.load function, not even the loop within it - this is the time it takes to print console.log("load").
By contrast, using the XLSX library here sheetjs/README.md at master - sheetjs - SheetJS I tried the following code to perform the same action:
if (event.target.files.length > 0) { this.importFile = event.target.files[0]; ////// XLSX const file: File = event.target.files[0]; this.importFile = file; const reader = new FileReader(); reader.onload = (e: any) => { /* Read the binary string */ const bstr = e.target.result; const workbook = XLSX.read(bstr, { type: 'binary' }); // this.worksheetList = workbook.SheetNames; this.availableWorksheetList = workbook.SheetNames; this.activeHeadersList = []; this.headersByWorksheetList = []; this.resetAllFields(); workbook.SheetNames.forEach(sheetName => { const currentWorksheet = workbook.Sheets[sheetName]; const data = XLSX.utils.sheet_to_json(currentWorksheet, { header: 1 }); // Check column headers if (data.length > 0) { // this.worksheetList = [...this.worksheetList, ...workbook.SheetNames]; this.headersByWorksheetList.push(new HeadersByWorkSheet(sheetName, data[0] as string[])); // First row contains headers } }); } reader.readAsArrayBuffer(file); }
This one performed the same action in under a second, which is much more reasonable. I wondered if there was something we could do to potentially replicate these speeds using the Infragistics Excel library?
Thanks!
Hello,
Current Behavior and Constraints
The IgxExcelCoreModule from Infragistics offers robust functionality for interacting with Excel workbooks. However, it creates a comprehensive object model of the workbook upon loading. This model includes all sheets, cells, styles, formulas, and metadata, which is why it takes significant time when processing large workbooks.
By contrast, SheetJS (XLSX) does not build a full object model. It focuses only on essential parts of the workbook, like headers and sheet names, resulting in faster performance. This difference in approach explains the significant discrepancy in load times.
Capabilities of IgxExcelCoreModule
Limitations in Your Use Case
Why Is This Happening?
The underlying design of the IgxExcelCoreModule prioritizes a rich feature set for advanced workbook manipulations. This results in more resource-intensive operations. Libraries like SheetJS are optimized for simpler tasks, such as quick access to sheet names and headers, without building a detailed model.
Potential Solutions
If you have control over how the workbooks are created:
For quick access to sheet names and headers, you can optimize the existing code by leveraging internal features of IgxExcelCoreModule or pre-filtering the data where possible.
Suggested Approaches to Address the Issue
To address the performance challenges while continuing to use the IgxExcelCoreModule, here are practical approaches tailored to your use case. These are intended to optimize performance and improve user experience.
Request for Isolated Sample
To better analyze the specific behavior you are encountering, I kindly request an isolated sample project that replicates the issue. The sample should include:
Conclusion
Given the current capabilities of the IgxExcelCoreModule, the above approaches will help optimize the performance while preserving its detailed functionality.
I encourage you to create an isolated sample project that replicates the issue using the guidelines provided earlier. This will allow us to analyze the problem thoroughly and provide more targeted optimizations. Thank you for your understanding, and I look forward to working together on this!
Regards,
Georgi Anastasov
Associate Software Developer
Infragistics
Hi,
Thanks very much for getting back to me with such a detailed response.
I think for the sake of our requirements, the simplest outcome is to stick with the latter solution I originally posted using the XLSX library since it provides us the limited functionality we require with the advantage of being considerably faster. The bulk of our excel manipulation (imports and exports) is handled on the backend of our system, so it wouldn’t make sense to try and utilise the Infragistics’ IgxExcelCoreModule to do something simpler than it seems designed to handle.
We’ll be unable to pre-filter the data on the workbooks themselves or break them into batches, as this is the whole point of what we are trying to achieve through this piece of functionality. It should allow the user to upload a potentially large workbook of data and quickly grab its sheet names and headers before sending the necessary DTO to the backend to be handled as the user sees fit while still keeping within the confines of our database requirements.
Thanks again for getting back to me, I will refer back to this if looking to use a more complex and robust frontend solution.