Portage uses a different algorithm called backtracking. Portage finds the package\u2019s use flags and backtracks the packages related to that use flag. It is recursive and the process repeats. The time complexity is O(N!) and I understood that\u2019s the reason portage is slow and not because of python. Even after hours of looking at the codebase it is hard to make sense of the exact workings. Due to the sheer number of features portage offers, the process is many folds complex than pacman. This can be understood by the fact that the dependency resolution part (not completely) of pacman is like 927 lines of c code<\/a> at the moment of writing this and the portage equivalent is about 11814 lines of python code<\/a>. I also had the code profiled and Here is the image version. Portage also uses granular, file level locks, whereas pacman uses one lock for the whole runtime.\u00a0 This allows multiple instances of portage to run at the same time.<\/p>\n Studying portage\u2019s codebase made it much easier for me to understand pacman\u2019s codebase and in no time, even though I don\u2019t have much experience in C. I am glad I got to work on portage, but also sad that I cannot understand the codebase enough (yet) to contribute in a deeper way. Portage is years of work of many smart minds and it is unreasonable of me to expect to understand things fast.<\/p>\n The second half of the week was towards finding something to improve on portage. I added a few type hints and refactored some big functions into smaller ones for better readability. Also found some unreachable code and removed them as well. I think they are nice improvements. I sent a pull request which can be found here<\/a>. It is not merged yet, I think it will be soon.<\/p>\n To summarize, the week was spent delving more into the cProfile results of portage and comparing it with pacman. I also refactored the codebase a little bit, which makes it a tiny bit better.<\/p>\n I want to look at portage\u2019s ability to resolve circular dependencies but I am not sure if I can do it (if it is a simple task). If it were simple, portage developers would have done it already, but I still want to give it a try. I\u2019ll keep you posted. That marks the end of week three. See you in week four\u2019s post!<\/p>\n","protected":false},"excerpt":{"rendered":" Week 3 – Modernization of Portage It is the third week of the coding period. It is mostly an uneventful week. Most part was spent on\u00a0 trying to understand the dependency resolution algorithm. In the second part of the week … Continue reading depgraph.py<\/code> alone takes like 95% of the total runtime. So it is useful to learn about the algorithm. The profiling results can be found here<\/a>.<\/p>\n![\"profile\"](\"https:\/\/gist.githubusercontent.com\/berinaniesh\/3da9bae3f06030117e2ab0c2f34c2df8\/raw\/de895501424c5709c620ffc4c92c574c04d44606\/profile.png\")
<\/p>\nRefactoring \/ Tidying up portage<\/h2>\n
Summary<\/h2>\n