[GH-ISSUE #45] worksheet_write_column api #39

New issue

Closed

opened 2026-05-05 11:27:39 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 11:27:39 -06:00

Owner

Originally created by @burlen on GitHub (Feb 3, 2016).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/45

Hi, I am about to start using your library, it is a god send that I don't have to do this from scratch, thank you!

After reading your API I have some concern about performance. I believe it would be easy to demonstrate as it is a well known issue with C API, a function call on an inner loop creates a bottleneck. Function calls themselves are rather heavy operation. Especially where memcpy would suffice.

I would like to know if you had planned on adding an API to set an entire column of data via a single call? If not I would like to propose it. Something along the lines of:

int8_t worksheet_write_column(lxw_worksheet *worksheet,
                              lxw_row_t num_rows,
                              lxw_col_t col_id, double *col_data,
                              lxw_format *format);
/*
worksheet - object to add the data to
num_rows - length of the array in rows
col_id - which column
col_data - pointer to c-array with one element per row
format - format object or NULL
*/

Given the loop structure illustrated in the doc section about memory and performance I believe such an API is compatible and would be almost trivial to add. Please let me know your thoughts on this issue.

Burlen

Originally created by @burlen on GitHub (Feb 3, 2016). Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/45 Hi, I am about to start using your library, it is a god send that I don't have to do this from scratch, thank you! After reading your API I have some concern about performance. I believe it would be easy to demonstrate as it is a well known issue with C API, a function call on an inner loop creates a bottleneck. Function calls themselves are rather heavy operation. Especially where memcpy would suffice. I would like to know if you had planned on adding an API to set an entire column of data via a single call? If not I would like to propose it. Something along the lines of: ``` C int8_t worksheet_write_column(lxw_worksheet *worksheet, lxw_row_t num_rows, lxw_col_t col_id, double *col_data, lxw_format *format); /* worksheet - object to add the data to num_rows - length of the array in rows col_id - which column col_data - pointer to c-array with one element per row format - format object or NULL */ ``` Given the loop structure illustrated in the doc section about memory and performance I believe such an API is compatible and would be almost trivial to add. Please let me know your thoughts on this issue. Burlen

gitea-mirror closed this issue

2026-05-05 11:27:42 -06:00

gitea-mirror commented

2026-05-05 11:27:45 -06:00

Author

Owner

@jmcnamara commented on GitHub (Feb 4, 2016):

Hi Burlen,

Thanks for the suggestion. The dynamic language versions of this library in Python, Perl and Lua have a function just like that.

However, for the way that libxlsxwriter handles its data internally this wouldn't help performance. Also, the library handles different data types (strings, numbers, formulas, urls, blanks) and each one of them would need a write_column() handler.

Thanks for the input.

John

@jmcnamara commented on GitHub (Feb 4, 2016): Hi Burlen, Thanks for the suggestion. The dynamic language versions of this library in Python, Perl and Lua have a function just like that. However, for the way that libxlsxwriter handles its data internally this wouldn't help performance. Also, the library handles different data types (strings, numbers, formulas, urls, blanks) and each one of them would need a `write_column()` handler. Thanks for the input. John

gitea-mirror commented

2026-05-05 11:27:48 -06:00

Author

Owner

@burlen commented on GitHub (Feb 4, 2016):

Yeah, browsing the source code, I'm noticing that under the covers things are not gearedtoward performance. Unfortunately, without a major rewrite this library isn't going to provide the level of performance we need. I'm glad we found this out now! Thanks for the feedback.

@burlen commented on GitHub (Feb 4, 2016): Yeah, browsing the source code, I'm noticing that under the covers things are not gearedtoward performance. Unfortunately, without a major rewrite this library isn't going to provide the level of performance we need. I'm glad we found this out now! Thanks for the feedback.

gitea-mirror commented

2026-05-05 11:27:51 -06:00

Author

Owner

@jmcnamara commented on GitHub (Feb 4, 2016):

No problem.

@jmcnamara commented on GitHub (Feb 4, 2016): No problem.

gitea-mirror commented

2026-05-05 11:27:53 -06:00

Author

Owner

@burlen commented on GitHub (Feb 4, 2016):

btw, I still think you have the best solution out there! Thanks so much for publishing it freely and interacting with the community!

@burlen commented on GitHub (Feb 4, 2016): btw, I still think you have the best solution out there! Thanks so much for publishing it freely and interacting with the community!