# Performance of reversing dyld shared cache

**URL:** <https://community.hex-rays.com/t/performance-of-reversing-dyld-shared-cache/657>\
**Category:** Bugs\
**Tags:** common-issue\
**Created:** [January 24, 2026, 7:22pm UTC](https://community.hex-rays.com/t/performance-of-reversing-dyld-shared-cache/657 "2026-01-24T19:22:03Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![yoavst](https://sea2.discourse-cdn.com/flex002/user_avatar/community.hex-rays.com/yoavst/32/124_2.png) [@yoavst](https://community.hex-rays.com/u/yoavst)\
**Post date:** [January 24, 2026, 7:22pm UTC](https://community.hex-rays.com/t/performance-of-reversing-dyld-shared-cache/657/1 "2026-01-24T19:22:03Z")

</div>

On Mac with M4 with IDA 9.2, when trying to work on a dyld shared cache with ~50 or more modules loaded, IDA become much more slows, including randoms hangups, long time for renames, …

Is it a known issue? is there a workaround for that? Because IDA can deal with kernelcache with all modules loaded (which is larger, and it runs much faster)

* * *

In addition, xrefs work poorly on shared cache. many GOT/STUBS functions has no xrefs, even though there are xrefs. I’m using [this](https://github.com/yoavst/ida-ios-helper/blob/master/src/scripts/fix_dyld_xrefs.py) script to fix it, but it should probably be fixed.

---

<div class="post-metadata">

**Author:** ![teresa\_hexrays](https://sea2.discourse-cdn.com/flex002/user_avatar/community.hex-rays.com/teresa_hexrays/32/11_2.png) [@teresa\_hexrays](https://community.hex-rays.com/u/teresa_hexrays)\
**Post date:** [January 28, 2026, 12:47pm UTC](https://community.hex-rays.com/t/performance-of-reversing-dyld-shared-cache/657/2 "2026-01-28T12:47:24Z")

</div>

Hi @yoavst and thanks for raising these issues. To avoid speculative answers, could you open a ticket via our [support channel](https://support.hex-rays.com/) with additional details and reproduction steps?

---

<div class="post-metadata">

**Author:** ![gilbo](https://avatars.discourse-cdn.com/v4/letter/g/45deac/32.png) [@gilbo](https://community.hex-rays.com/u/gilbo)\
**Post date:** [May 25, 2026, 12:16am UTC](https://community.hex-rays.com/t/performance-of-reversing-dyld-shared-cache/657/3 "2026-05-25T00:16:13Z")

</div>

Hi,

This is still a major issue when reversing the dyld shared cache. Is there any update on this?

A current dyld shared cache from an iOS firmware contains more than 4,000 images. Loading and analyzing all of them in a single IDB is practically impossible.

The `dscu` plugin is definitely a major improvement, since most workflows do not require every module to be loaded at once. However, it still does not seem to scale well, regardless of the hardware being used.

Some interactive operations also become very slow. I wonder whether this may be caused by internal data structures or algorithms that do not scale well with the amount of information being loaded.

More broadly, it would be extremely helpful if IDA could make better use of multi-core systems, especially during auto-analysis. I understand that this may be difficult to implement, since some analysis stages likely depend on earlier results, but it seems there should still be room for more parallelism in the analysis pipeline.

On a positive note, `idalib` has been a great addition. Analyzing binaries without the GUI also seems to provide a noticeable performance improvement.

Thanks.

---

<div class="post-metadata">

**Author:** ![teresa\_hexrays](https://sea2.discourse-cdn.com/flex002/user_avatar/community.hex-rays.com/teresa_hexrays/32/11_2.png) [@teresa\_hexrays](https://community.hex-rays.com/u/teresa_hexrays)\
**Post date:** [May 27, 2026, 2:26pm UTC](https://community.hex-rays.com/t/performance-of-reversing-dyld-shared-cache/657/4 "2026-05-27T14:26:02Z")

</div>

Hi All,

A quick follow-up: with the 9.4 release, we aim to improve the DSC workflow, and with the upcoming fixes, we expect it to be _much_ leaner.  
We’d be happy to invite you to our [beta program](https://hex-rays.com/beta-program) if you’d like to test it and share some feedback.

---

<div class="post-metadata">

**Author:** ![gilbo](https://avatars.discourse-cdn.com/v4/letter/g/45deac/32.png) [@gilbo](https://community.hex-rays.com/u/gilbo)\
**Post date:** [June 30, 2026, 1:21am UTC](https://community.hex-rays.com/t/performance-of-reversing-dyld-shared-cache/657/5 "2026-06-30T01:21:13Z")

</div>

Good improvements on the workflow, one thing that is really missing is having the ability to load a binary into a dyld shared cache IDB.

Since most of the libraries imported from a binary are in the DSC it would be really useful to load a standalone Mach-O into the same IDB as the DSC (potentially also resolving xrefs to its imports this way..)

Currently attempting to load such Mach-O crashes IDA completely.

---

<div class="post-metadata">

**Author:** ![gilbo](https://avatars.discourse-cdn.com/v4/letter/g/45deac/32.png) [@gilbo](https://community.hex-rays.com/u/gilbo)\
**Post date:** [June 30, 2026, 1:21am UTC](https://community.hex-rays.com/t/performance-of-reversing-dyld-shared-cache/657/6 "2026-06-30T01:21:51Z")

</div>

Additionally, doesn’t seem like the IDB handles the scale issue better, can you elaborate if you did improve that ?

---

<div class="post-metadata">

**Author:** ![igor](https://sea2.discourse-cdn.com/flex002/user_avatar/community.hex-rays.com/igor/32/35_2.png) [@igor](https://community.hex-rays.com/u/igor)\
**Post date:** [June 30, 2026, 7:23am UTC](https://community.hex-rays.com/t/performance-of-reversing-dyld-shared-cache/657/7 "2026-06-30T07:23:23Z")

</div>

Hi,

Have you tried the [9.4 beta](https://docs.hex-rays.com/release-notes/9_4beta)?

If yes and it still crashes, please [file a bug](https://support.hex-rays.com/) with the detailed reproduction steps. Unfortunately, it is not evident what is the exact scenario from your short description.
