Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: reduce RAM consumption #43

Open
Danaozhong opened this issue Feb 16, 2020 · 2 comments
Open

Feature request: reduce RAM consumption #43

Danaozhong opened this issue Feb 16, 2020 · 2 comments

Comments

@Danaozhong
Copy link

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.

@seleznevae
Copy link
Owner

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.

@bmedici
Copy link

bmedici commented Oct 23, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants