Fix data storage problems#30
Conversation
Dependencies are now organized using maps and sets. This ensures that no duplicate entries occur. As there are more lookups than direct acesses and real iterations this should be running faster than the original approach. Internally it reduces the worst case complexity from n^4 to n^2*log(n)^2 where n is the number of files. The worst case complexity of external shell calls is reduced from n^3 to n^2. Unhandled files are saved in a queue so that we can merge Dependencies directly. This is not expected to solve all issues with the program so far.
|
Hi, thanks for the contribution, though this is a pretty huge change and I must admit I don't really have the time to review/test all of that at the moment, so I'm not too sure how to handle that TBH. I'd appreciate if other dylibbundler users could give a hand with testing this and report on whether these changes work for them |
|
Hi, other users probably won't find this pull request. So this is not an option. Then you should make sure the test suite compiles properly. |
|
dylibbundler is a little project I made years and years ago, and I am no longer actively working on it. actually, if someone else volunteered to take over the project, I would gladly let other peoples take a look at it since I just have very little time to invest on it, sorry... I know it's not ideal to let pull requests like that but at this time I am unable to do more |
2 participants
Hi, with my project I got some strange behaviour of dylibbundler.
Two examples:
https://travis-ci.org/keinstein/mutabor/builds/359407671
https://travis-ci.org/keinstein/macdylibbundler/builds/365191186
Click on one of the builds to see the log files of the builds.
As I don't own a current Mac I used address sanitizer in order to debug dylibbundler. I couldn't figure out the cause of this strange behaviour. But changing to tree based data structures solved the index problems. Other problems have been solved, too.
Other changes: