Anton Korobeynikov

> Yes, that matches our observations. We were discussing if precompiled headers would be something that could help with this, but I don't think we got to a serious try....

And this one is interesting: ``` 15929 ms: Util::CompilerBug::CompilerBug (440 times, avg 36 ms) ``` Actually, every `BUG_CHECK` leads to such instantiation, depending on the types of arguments. Maybe there...

> We could move the `toString` to `big_int_utils` here? `big_int` is primarily (only?) used for constants. Maybe we can do something there... The problem is header boost dependency. So, moving...

> Not sure I follow. If we move out `toString` for `big_int` we can at least get rid of the `big_int` include there. We could also try to forward declare...

> I am thinking it is not that widely used. Usually only in places where we work with constants. It might be possible to factor it out. Ok, maybe good...

@vlstill One step at a time. There is no single place that contributes to the compile time, but 7% improvement is already a lot.

> I am thinking it is not that widely used. Usually only in places where we work with constants. It might be possible to factor it out. Well, the thing...

The error in log is completely unrelated to that warning. First of all, starting from Monterey it is not possible to really limit the used memory in many circumstances unless...

> The system has 4TB free space. Error is reproducible. What do you recommend? Check system limits on number of open files? E.g. via `ulimit -n`? Usually it is very...

> I've increased to 1,000,000 `ulimit -S -n 1000000` but result is the same Did it really increase the limit? Have you checked via `ulimit -a`? Note that you cannot...