VeriFIT/mata

Speed-up the building of the binding.

Closed this issue · 4 comments

The issue is simple. The building of python binding is opressively fucking slow.

I think the main issues are:

  1. The Cudd library is too big, and could be made smaller.
  2. Some of the packages do not require all of the sources and I fear they are recompiled for each package. Currently, the easiest way was to include everything, since there are lots of depedencies, but alphabets and utils could probably be considerably reduced. Alternatively check, if one can exploit some caching of built files, or link the compiled files in other way (there should be some options in setup.py build_ext for linking)

Note: Since we should go for pyproject.toml this might go obsolete.

Note: seems that ubuntu-latest has only 2 cores, so it would be nice to find some optimization.

Adda0 commented

I would suggest looking into pyproject.toml first. If it solves the issues with building as a by-product of converting to it from setup.py, there is no need to optimize the compilation with the current build system.

Yes, that is for sure. Still, since it takes too long, and investment into moving from setup.py might take some time, I want to look at some quick fixes (I checked some cython directives, but so far no success; might look at compiler directives and some quick simplification of the source code lookup). Since others (namely just you :D) might put out their PR, I would like to have some faster build-up (currently it takes ~5min at my enviorment, but 20min in GA: mostly because of the 2 cores I fear).

Adda0 commented

Good points. If you find something quickly to improve the performance, I am all for it. In my opinion, even 20 min (it usually takes about 14 min from what I have seen for now) in GA is acceptable. The problem I have is that I build Python binding locally in about 12 min. Which is strange, considering I build it on 6 cores, whereas on 2 cores it takes only 14 min. Maybe the cores are not allocated by the build process in my case? I am not sure.