You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The library has a relatively high RAM footprint, making it difficult to use on low-spec embedded systems. Printing a table with 4 or 5 rows easly allocates several kB of RAM.
Jumping in the code, I noticed that in the background buffers are allocated for each cell of the table, before printing starts.
Would it be possible to selectively draw the table in lines? For example, something like this:
for (size_t i = 0; i != ft_get_number_of_rows_to_print(table); ++i)
{
memset(buffer, 0, 128);
if (0 == ft_print_single_row(table, i, buffer, 256))
{
printf(buffer);
}
}
So that in the background, only the necessary allocations are done for a single row, and the buffers are freed after printing out.
Judging from the code, this would mean major code changes regarding the cell buffer handling.
The text was updated successfully, but these errors were encountered:
Hi!
From the very beginning memory usage cpu usage were simply out of scope. For my use case different feature and flexibility for different styles were more important. That's why I put more effort into it. So, yeah, it is very possible that memory consumption is relatively big.
First, of all I'll try to find some time to revise and profile current code. Maybe some small places can be rewritten to reduce memory and cpu consumption, and reduce redundant memory allocations on the heap without changing external API.
About adding possibility to convert table to string not as a whole but row by row (or by group of the rows). The idea seems rather interesting. I also thought about something like that some time ago but for a little bit different other use case. Also I like the idea of providing memory buffer to the library very much.
To achieve such goals it will be needed to rewrite a relatively big amount of code. So I think it will be good to put some time in planning and thinking about the API to make it more general and how it will interact with current code.
So at the moment can't say anything really certain. I'll revise code and will determine what can be done relatively easy and somehow plan other taks as big features.
Hi all,
I second that. Using this lib on an ESP32 needs A LOT OF PRECIOUS RAM, for a simple 2kB output of text, up to 10kB of RAM is sucked in. I just can't continue using it on such limited devices.
The library has a relatively high RAM footprint, making it difficult to use on low-spec embedded systems. Printing a table with 4 or 5 rows easly allocates several kB of RAM.
Jumping in the code, I noticed that in the background buffers are allocated for each cell of the table, before printing starts.
Would it be possible to selectively draw the table in lines? For example, something like this:
So that in the background, only the necessary allocations are done for a single row, and the buffers are freed after printing out.
Judging from the code, this would mean major code changes regarding the cell buffer handling.
The text was updated successfully, but these errors were encountered: