Libreoffice custom import - getCellByPosition bottleneck

I am currently creating a custom importer/exporter for my own file type with java using XFilter.

I now have a serious bottleneck when importing. Here is my code for inserting my content into a spreadsheet:

XSpreadsheetDocument document = UnoRuntime.queryInterface(
    XSpreadsheetDocument.class,
    targetDocument);
XMultiServiceFactory serviceFactory = UnoRuntime.queryInterface(
    com.sun.star.lang.XMultiServiceFactory.class,
    document);

for (int i = 0; i < numberOfSpreadsheets; i++) {
    Object spreadsheetObject = serviceFactory.createInstance("com.sun.star.sheet.Spreadsheet");
    XSpreadsheet spreadsheet = UnoRuntime.queryInterface(
        XSpreadsheet.class,
        spreadsheetObject);
    document.getSheets().insertByName(spreadsheetNames.get(i), spreadsheet);
    
    // Not sure about this part
    spreadsheet = UnoRuntime.queryInterface(
        XSpreadsheet.class, 
        document.getSheets().getByName(spreadsheetNames.get(i));

    for (int rowIndex = 0; rowIndex < numberOfRows; rowIndex++) {
        for (int columnIndex = 0; columnIndex < numberOfCellsInRow; columnIndex++) {
            // This call to getCellByPosition seems to be the bottleneck
            XCell cell = spreadsheet.getCellByPosition(columnIndex, rowIndex);

            XText text = UnoRuntime.queryInterface(XText.class, cell);
            text.setString(cellValue);
        }
    }
}

Is there any way I can omit all these calls to getCellByPosition?
Is there some sort of bulk API available?

Look at XCellRangeData’s setDataArray.

The issue with this is that I have to be able to format the cells. The setDataArray function is fast, but formatting the cells afterwards is slow.

Heh, good to hear about additional important requirements not mentioned in the initial post (only telling about data)…

Well - I suppose that unless you apply formatting to big ranges at once (like to columns), there’s no way to improve speed if you want to handle cells one-by-one. I would be glad to be proven wrong.

Sorry about that. So then the problem really is the link between my extension and LO? Because native importers are very fast by comparison.

I tried implementing XExportFilter and XDocumentHandler for the export, but it is also very slow. So it seems to be the link between my extension and LO.

Well - UNO is rather slow. “Native” importers are fast because they work with internal structures… Some of built-in importers for XML types are (were? they are being converted to use orcus) using XSLT - and they are also very slow.