Type cache constantly rebuilding

Using exporter 4.4.0-beta, the two inspector integrations for the AI-thingy and opening the ts-component are using different project path formats. This way the type cache gets rebuilt two times per custom MonoBehaviour, whenever the inspectors are created/initialized, leading to a very sluggish inspector experience and lots of allocations.

Everything works smooth again after changing InspectorComponentLink.cs:158 to

if (exportInfo) _lastProjectDirectory = exportInfo.GetProjectDirectory();

Hi Krizzl0r,

Thank you for your contribution regarding the issue of the type cache rebuilding. It seems you’ve identified that changing the line in InspectorComponentLink.cs to set _lastProjectDirectory using the method exportInfo.GetProjectDirectory() resolves the performance issues associated with the multiple cache rebuilds.

This change indeed sounds like a solid solution to streamline the inspector experience. By ensuring that all components utilize a consistent project path format, you can avoid the need for the type cache to rebuild unnecessarily.

If you’re looking to implement this change or share it further, you should ensure that other developers are aware of this workaround. Additionally, consider running some tests post-implementation to confirm that performance is enhanced across different setups without introducing new issues.

If you need further assistance with integrating this modification or have additional questions regarding Needle Engine, feel free to ask! You can also check the Needle Engine documentation for more insight on how to effectively manage components and performance optimizations.

Let me know how else I can assist you!

0 replies left - Get a PRO license for more AI replies.
thread_sa5TL2xXovkQcL6O1Z4cO34r
Reply to this message to continue the conversation

@marwie1 sorry for keeping you guys so busy today – I’m working through a list of aftermath’y kind of stuff here.

This is still a problem. And it grows with types in the project and component count on individual GameObjects. In my current use case I have ~1s of wait time when switching between GameObjects.

Good news is the fix above still works too :smiley:

I’m kind of surprised this is no obvious problem on your end on on other user’s projects though. I could still see the same behaviour on a colleagues machine working on the same project.

Hi Krizzl0r,

The ongoing delay when switching between GameObjects, scaling with your project’s types and component count, points strongly to the type cache rebuild caused by inconsistent project path formats as a central bottleneck.

Since your fix setting _lastProjectDirectory via exportInfo.GetProjectDirectory() reduces rebuild frequency effectively, it’s likely key for avoiding redundant cache invalidations. The persistence of the issue on a colleague’s machine working on the same project further confirms the underlying cause.

For further diagnosis and improvement, I suggest:

  1. Verifying consistent project path usage globally: Ensure all inspector-related integrations align on the same project path format, not only in InspectorComponentLink.cs but wherever they manage export or type cache references.
  2. Profiling cache rebuild triggers: Use profiling tools or insert debug logs to confirm exactly when and why the type cache rebuilds. Check if some other components or editor extensions might inadvertently trigger rebuilds.
  3. Checking your Unity, exporter, and Needle Engine versions: Differences here can cause inconsistent behavior. If possible both you and your colleague should match versions exactly, especially the exporter.
  4. Reproducing with minimal project: Try creating a minimal reproduction of the issue to share with the Needle Engine maintainers or community for deeper insights.

This is a significant perf hit for large projects, so your fix is very valuable. If you want, I can help draft a concise bug report for the Needle Engine issue tracker or help you create a test case for further investigation.

Let me know if you want help with profiling, debugging, or submitting feedback!

0 replies left - Get a PRO license for more AI replies.
thread_sa5TL2xXovkQcL6O1Z4cO34r
Reply to this post directly if you need further help (bottom right button)

Hi @krizzl0r it’s indeed surprising that it hasn’t been reported by anyone else yet (or noticed by someone in the team). However I see how this can be a problem and be simplified. I’ll look at it right now

1 Like

Please update to 4.5.0-alpha (e.g. via Unity’s PackageManager) and let me know if that fixes the issue for you

Yep, fixed!