search

kam800 / MachObfuscator

MachObfuscator is a programming-language-agnostic Mach-O apps obfuscator for Apple platforms.
MIT License
521 stars 78 forks source link

Simple time measurement. Parallel loading of system headers #51

Closed kjamroz-bt closed 5 years ago

kjamroz-bt commented 5 years ago

Some performance improvements thank to parallel processing.

kjamroz-bt commented 5 years ago

For app that I use for tests headers loading time had 50% improvement (from ~20s to ~10s). Total runtime for my app is about 50s.

Other slow part of processing is looking for dependencies. For my app it takes 15-20s. It loads every dependency, but it seems to me that the same files (common for different modules like libc) are loaded repeatedly. I believe this cannot be simply parallelized due to RpathsAccumulator and checking if dylib resolves consistently (fatalError: "ambiguous resolved dylib locations"). I thought about caching based on physical resolved path but it is deeper change.

I have an app with about 50 embedded frameworks and dylib. I run tests on Mac Book Core i5, 2 cores + HT. Times are for release build, debug build is slower.

kam800 commented 5 years ago

About repeated loading, we could provide caching loader: https://github.com/kam800/MachObfuscator/blob/299d8ab5fa7071e3f28d5dc5126776293311ccaf/MachObfuscator/Controller/SimpleImageLoader.swift#L3

kjamroz-bt commented 5 years ago

I think the problem is not with loading image to memory, which should be rather fast (if I understand correctly, it uses memory mapped file). What takes time is repeated analysis of the same image: loading dependent images from imports and cstrings. Some dynamic programming could improve run time for this analysis.