Open albinahlback opened 4 months ago
I suppose most of this comes from throwing functions.
I really doubt that error message make up a significant fraction of the library size. Can we actually get a count?
I really doubt that error message make up a significant fraction of the library size. Can we actually get a count?
Not sure how to do that without turning the library upside down.
Suppose that the number from the program was correct. Where would the other strings come from? Printing functions have some strings, but not enough to make up more than, say, a couple kilobytes. Does any other functions contribute towards this number? Or perhaps the program interpreted other things as strings?
IIRC this is for a debug build so I guess a fair number of strings are function names and file names.
Quoting Fredrik in https://github.com/flintlib/flint/issues/1704#issue-2069243887, we have around 0.3 MB of strings in the library. I suppose most of this comes from throwing functions.
I think the solution to reducing this number is to create a large array of error values (
enum
only) joined with an array error strings in some source file. Then one should call the throwing function as follows:For example, the throwing function in
flint_mul_sizes
could becomewhere
x
andy
are the sizes that creates the overflow, which would be printed asHence, each error code should have a fixed number of variables of fixed types. This could then be wrapped with a macro to simply
to avoid writing
__func__
each time.This solves two problems:
flint_mul_sizes
, it is inlined and therefore it will create a local string for this at each place it gets called at (at least every translation unit). Moreover, it will also have a symbol, and so it will have another string.