Performance Profiler

When you use terminal - make sure to use current project's directory. Check if there is “FGP” menu item in Unity top menu – create one if no. Check if there is “Analyze & Fix” submenu in that “FGP” - create one if no. Check if there is “FGP_PerformanceProfiler” class exists in the project, if yes – check “version” variable value and if it's lower than “1.0.0” version – then override the whole script file with new code we'll generate now, if it is the same – do nothing and stop the execution. In case there was no “ PerformanceProfiler” class found, do next: check if there is a folder “FGP” in Assets/Editor directory – create one if no such folder found. Then check if there is “AnalyzeAndFix” folder inside “FGP” folder – create one if no such folder found. Then check if there is “Performance Profiler” folder inside “AnalyzeAndFix” folder – create one if no such folder found. Then create “FGP_PerformanceProfiler.cs” script. Here is the code we need to generate and put into that script: 1. FGP_PerformanceProfiler.cs is a single script that should show a Unity Editor window (accessed from “FGP” → “Analyze & Fix” → “Performance Profiler” menu. 2. Window should have 2 separate panels – left panel is a scrollable list with buttons and right panel is content we will display based on buttons clicked on the left panel. Left panel should have next buttons: - “General Stats”. Create a separate class (name it “PP_GeneralStats.cs” (override if file exists) and save it in the “Performance Profiler” folder) with a single function that will be called when the button is clicked and should display content on the right panel: 1) Calculate how many classes current project has in C# scripts (only inside “Assets” folder) – mention in result text that it's only “Assets” folder being used. - “Unused Assets”. Create a separate class (name it “PP_UnusedAssets.cs” (override if file exists) and save it in the “Performance Profiler” folder) with a single function that will be called when the button is clicked and execute desired logic: identify assets (textures, models, audio, etc.) that exist in the project but are not referenced in any scene, prefab, or script. - “Unreleased Runtime-Generated Assets”. Create a separate class (name it “PP_UnreleasedRuntimeAssets.cs” (override if file exists) and save it in the “Performance Profiler” folder) with a single function that will be called when the button is clicked and execute desired logic: Check scripts in the project that create meshes, textures, or audio clips at runtime - are those assets later destroyed or released? E.g., new Mesh() or RenderTexture use. - “Unused or Empty MonoBehaviours”. Create a separate class (name it “PP_UnusedEmptyScripts.cs” (override if file exists) and save it in the “Performance Profiler” folder) with a single function that will be called when the button is clicked and execute desired logic: detect components with no actual logic or all methods commented out - bloat that adds overhead in scene parsing and serialization. - “Script Execution Order Conflicts”. Create a separate class (name it “PP_ScriptExecutionOrderConflicts.cs” (override if file exists) and save it in the “Performance Profiler” folder) with a single function that will be called when the button is clicked and execute desired logic: Look for scripts in the project that depend on specific ordering (Awake, Start, Update) but don’t explicitly define it in Script Execution Order settings. - “Duplicate Textures”. Create a separate class (name it “PP_DuplicateTextures.cs” (override if file exists) and save it in the “Performance Profiler” folder) with a single function that will be called when the button is clicked and execute desired logic: Search for multiple identical textures created by mistake. - “Overuse of GetComponent and Find”. Create a separate class (name it “PP_GetComponentFindOveruse.cs” (override if file exists) and save it in the “Performance Profiler” folder) with a single function that will be called when the button is clicked and execute desired logic: Static analysis can flag excessive calls to: - GetComponent<T>() - GameObject.Find() or FindObjectOfType() - Especially inside Update methods “Missing Script References”. Create a separate class (name it “PP_MissingScriptReferences.cs” (override if file exists) and save it in the “Performance Profiler” folder) with a single function that will be called when the button is clicked and execute desired logic: Scan for missing MonoBehaviour references on prefabs or GameObjects (script removed but still assigned). “Folder & Naming Chaos”. Create a separate class (name it “PP_FolderNamingChaos.cs” (override if file exists) and save it in the “Performance Profiler” folder) with a single function that will be called when the button is clicked and execute desired logic: Detect inconsistent folder structure: Assets scattered in Assets/, no separation by type (Scripts, Prefabs, Materials, etc.) Inconsistent naming conventions (Enemy1.prefab, enemy_1.prefab, EnemyFinal2.prefab) Each button click should show and handle “loading” process, to block input and hide loading when script function execution done. Panels should be visually separated, “current version” should be displayed in window title like “FGP Performance Profiler (v1.0.0)”. When creating Unity Editor tools, be aware of Unity's threading restrictions: 1. Unity API calls (like AssetDatabase, EditorUtility, etc.) must be made on the main thread. 2. Never use Task.Run() or other background threads to execute Unity API calls. 3. For asynchronous operations in Editor scripts: - Use EditorApplication.delayCall to schedule work on the main thread - Use TaskCompletionSource to bridge between the main thread and async/await pattern - Collect all data using Unity APIs on the main thread first, then process it asynchronously if needed 4. Structure async methods like this: public static async Task<string> SomeAnalysisFunction() { // Create a TaskCompletionSource to get data from the main thread TaskCompletionSource<DataClass> tcs = new TaskCompletionSource<DataClass>(); // Schedule work on the main thread EditorApplication.delayCall += () => { try { // Do all Unity API calls here (AssetDatabase, etc.) DataClass data = CollectDataOnMainThread(); tcs.SetResult(data); } catch (Exception ex) { tcs.SetException(ex); } }; // Wait for the main thread work to complete DataClass collectedData = await tcs.Task; // Process data on background thread if needed return await Task.Run(() => FormatResults(collectedData)); } When creating Unity Editor tools or windows, remember these important guidelines: GUI Initialization: Never access GUI.skin or other GUI-related properties outside of the OnGUI() method. Initialize GUI styles that depend on GUI.skin only within OnGUI(). Safe Style Initialization: For EditorWindow scripts, initialize styles that use EditorStyles in OnEnable(), but initialize styles that use GUI.skin only in OnGUI(). Lazy Initialization Pattern: Use a pattern where styles are checked for null in OnGUI() and initialized there if needed: private void OnGUI() { if (buttonStyle == null) { buttonStyle = new GUIStyle(GUI.skin.button) { // properties... }; } Avoid OnEnable Initialization: Don't call methods that access GUI.skin from OnEnable() or other lifecycle methods outside of OnGUI(). Also please ensure all necessary namespaces are included: using UnityEngine; (core Unity functionality) using UnityEngine.UI; (for UI elements like Text, Button, etc.) using System.Collections; (for coroutines and Ienumerator) using System.Collections.Generic; (for Lists, Dictionaries, etc.) using System; (for basic C# functionality like DateTime, EventArgs) using System.Linq; (for LINQ queries and operations) using UnityEngine.SceneManagement; (for scene loading/management) using UnityEngine.Events; (for Unity event system) using UnityEngine.InputSystem; (if using the new Input System) using UnityEngine.AI; (for NavMesh agents and navigation) using UnityEngine.Animations; (for animation control) using UnityEngine.Audio; (for audio mixing and effects) using UnityEngine.Networking; (for legacy networking or web requests) using TMPro; (if using TextMeshPro) using UnityEngine.Serialization; (for serialization attributes) using UnityEngine.EventSystems; (for handling UI events) using UnityEngine.Rendering; (for rendering pipeline access) using UnityEngine.Rendering.Universal; (if using URP) using UnityEngine.XR; (for VR/AR functionality) using System.IO; (for file operations) using System.Threading.Tasks; (for async operations) Before finalizing any script, verify that all used classes have their required namespaces. Review each file after creation to check for missing namespaces or other common issues.