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

What is the practical meaning of SL_INDEX_COUNT_LOG2? #25

Open
kisvegabor opened this issue Mar 4, 2022 · 0 comments
Open

What is the practical meaning of SL_INDEX_COUNT_LOG2? #25

kisvegabor opened this issue Mar 4, 2022 · 0 comments

Comments

@kisvegabor
Copy link

Hi,

I made a test with an 64 bit i5 CPU using 1MB pool size with different SL_INDEX_COUNT_LOG2 settings and allocation sizes.

The algorithm:

    size_t alloc_size = 1; //or 8 or 1024;
    void * p;
    uint32_t c = 0;
    do {
        p = lv_mem_alloc(alloc_size); //Just a wrapper around tlsf_alloc
        c++;
    }while(p);

    //Uses lv_tlsf_walk_pool to get some memory info
    lv_mem_monitor_t m;
    lv_mem_monitor(&m);

    printf("count: %d, free: %d\n", c, m.free_size);
    return 0;

The results:
alloc_size=1

  • SL_INDEX_COUNT_LOG=5 count: 32415, free: 0
  • SL_INDEX_COUNT_LOG=1 count: 32510, free: 0

alloc_size=8

  • SL_INDEX_COUNT_LOG=5 count: 32415, free: 0
  • SL_INDEX_COUNT_LOG=1 count: 32510, free: 0

alloc_size=1024

  • SL_INDEX_COUNT_LOG=5 count: 1006, free: 80
  • SL_INDEX_COUNT_LOG=1 count: 1009, free: 24

So with SL_INDEX_COUNT_LOG=1 always more blocks were allocated, I guess it's because of the smaller control_t overhead.

Hence, SL_INDEX_COUNT_LOG=1 always seems better than 5, but I probably I miss something. Could you comment on this?

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

1 participant