Issue №3367 opened by Starbuck5 at 2022-08-01 07:56:42

This is a bit of a strange idea, but I thought I would put it out there.

colordict.py is 26kb
colordict.colors is 18.5kb of memory at runtime (measured using sys.getsizeof)
colordict.colors puts a python dict in between parsing a string color name and the translated color (performance?)

So, this might be worth implementing our own tiny dictionary inside color.c to handle this more efficiently. We can control the hash function and bucket size to maximize the benefit for our use case.

We also might be compress the data a bit more, filesize wise.

Here's a small example of what the frozen data could look like.

struct ColorDataStruct {
    char* name1;
    char* name2;
    int hex;
}

static ColorDataStruct colordata[] = {
    {"grey0", "gray0", 0x000000FF},
    {"tomato", NULL, 0xFF6347FF},
    {NULL, NULL, NULL}
}

There are two name slots because between the 665 color names there are only 507 unique color outputs.

Additionally, a C compiler might do string interning on all the similar names "grey0", "grey1", ... "grey99" for instance, reducing binary size.

Comments

# # ankith26 commented at 2022-08-03 05:21:36

I'm not sure a C compiler would do string interning on strings that are similar yet not the same (atleast I did not find anything online from a quick search)

I'm also not sure if this can give any significant change in performance (if benchmarks show otherwise I'd be happy to stand corrected), infact a naive C implementation (that uses iteration) could actually end up being slower than the python dict implementation (which as you know uses hashes so dictionary lookup is O(1))

So I personally don't think chasing this issue is worth the efforts needed (gains, even if present, would likely be minor), but if anyone wants to do it I'd be happy to review a PR nonetheless.