'Tabs.AnalyzeWindowLayout' causing lag in game view.

RyanL 11 months ago updated 10 months ago 4

Hi there. Using Peek 1.2.0f2 (already upgraded from 1.2.0f1, thanks for the quick response), I've noticed that 'Tabs.AnalyzeWindowLayout()' is taking a considerable amount of time in my main project, specifically 'Resources.FindObjectsOfTypeAll()'. 

In a new test project with only cubes, the time taken by this function is imperceptible. However, in my main project, the function is taking up to 18+ ms per frame according to the deep profiler while playing the game in the editor. See the attached screenshot.

I suspect that the call 'Resources.FindObjectsOfTypeAll()' isn't scaling well with projects that have a lot of resources? Such as it is, returning from this function while in gameplay by inserting this at line 77 in Ludiq/Ludiq.Peek/Editor/Tabs/Tabs.cs acts as a patch that is sufficient for my needs:

if (EditorApplication.isPlayingOrWillChangePlaymode) return;


Unity Version:
Peek Version:
Satisfaction mark by RyanL 10 months ago
Working on Fix

Hi Ryan,

Thanks again for the detailed report and I apologize for the performance issue.

I'm looking into this right away.

The issue is that, as far as I know, Unity has no event to let Peek know that the window layout has changed, which we need for setting up Tabs, so we need to poll it pretty much constantly.

I'll try to be more clever about that. Ideally, this function wouldn't run every frame, even in Edit mode. Your hotfix sure will help in Play mode, but I'd like to avoid a performance drop even in Edit mode.

Fixed (Unreleased)

Hi Ryan,

I've figured out what I think is a clever way of detecting potential window layout changes. In the next version, I'll only analyze the window layout if the active window changes, or if it gets maximized or minimized. This should make the check punctual, not at every frame, even in edit mode.

The code will roughly look like this:

        private static void WatchWindowLayout()
            var focusedWindow = EditorWindow.focusedWindow;
            var isMaximized = focusedWindow != null && focusedWindow.maximized;

            if (focusedWindow != lastFocusedWindow ||
                isMaximized != lastFocusedWindowWasMaximized)
                lastFocusedWindow = focusedWindow;
                lastFocusedWindowWasMaximized = isMaximized;

Thanks for the fix in v.1.3.0! The performance issue has been resolved in my main project.