ScriptableObject asset selection slows editor

Hi,
i made a CustomInspector for a ScriptableObject asset which holds a really big list of relatively simple objects (int, int, string, byte[5]). In OnInspectorGUI i draw a label for each of these inside a scrollview. I already optimized the drawing by not drawing the ones outside of the viewable rect and caching a lot of things/only updating on changes. The interesting thing here is, that even when i return; right at the beginning of OnInspectorGUI (not drawing anything) Unity is really laggy/extremely busy doing something, but i can’t find out what.
Any ideas what i can do?

Edit: the profiler shows that OnInspectorUpdate takes up almost all resources (cpu 99%) under ActiveEditorTracker.VerifyModifiedMonobehaviours()

Edit2:

I doubt code will help but here is the CustomInspector (i left out some variables which are self explaining and notice the return at the beginning!):

List<SBLocalizedString> cached = new List<SBLocalizedString>();
    public override void OnInspectorGUI()
    {
        return; //**notice this!**
        SBLocalizedStrings sls = target as SBLocalizedStrings;
        float inspectorHeight = Screen.height - 74;
        float inspectorWidth = Screen.width - 20;
        GUI.Label(filterLabelRect, "LanguageFilter:");
        EditorGUI.BeginChangeCheck();
        filter = EditorGUI.IntField(filterInputRect, filter);
        if (EditorGUI.EndChangeCheck())
        {
            if (filter > 0)
            {
                cached.Clear();
                foreach (SBLocalizedString s in sls.GetFiltered(filter))
                {
                    cached.Add(s);
                }
            }
            else
            {
                cached.Clear();
                cached = new List<SBLocalizedString>(sls.Strings);
            }
        }
        scrollPos = GUI.BeginScrollView(new Rect(0, 60, inspectorWidth + 20, inspectorHeight-20), scrollPos, new Rect(0, 0, inspectorWidth, elementHeight * cached.Count));
        for (int i = 0; i < cached.Count; i++)
        {
            float elementY = i * elementHeight;
            if (elementY < scrollPos.y)
            {
                continue;
            }
            ShowSingleEntry(new Rect(5, elementY, inspectorWidth, elementHeight), cached*);*

if (elementY >= scrollPos.y + inspectorHeight)
{
break;
}
}
GUI.EndScrollView();
}

private void ShowSingleEntry(Rect r, SBLocalizedString s)
{
GUI.Label(r, string.Format(“{0,-8} {1}: {2}”, s.ID, s.LanguageID, s.Text), EditorStyles.label);
}
And the Base class class:
[System.Serializable]
public class SBLocalizedString
{
public int ID;
public int LanguageID;
public string Text;
public byte[] extraData;
}

public class SBLocalizedStrings : ScriptableObject
{
[SerializeField, HideInInspector]
private List strings = new List();
public List Strings { get { return strings; } }

public IEnumerable GetFiltered(int language)
{
for (int i = 0; i < strings.Count; i++)
{
if (strings*.LanguageID == language)*
{
yield return strings*;*
}
}
}
}
The editor will only slow down if the asset of this class is selected. I think Unity is somehow comparing the serialized data every frame to the current state for internal purposes and because the list is really big this is slow (not sure, but i guess around 3k to 5k entries)

@ValooFX: Unity uses wrapper classes (SerializedObject, SerializedProperty) for every “thing” that is serialized. Each time your inspector is drawn Unity will update all those wrappers by calling ScriptableObject.Update. This will copy the values into the wrapper classes. Usually when the GUI has changed (GUI.changed == true) you would call ApplyModifiedProperties which will actually copy the values back to the actual object. That is of course quite inefficient for that many values.

Localization data (especially when you have that much data) is best stored in a text file in some human readable format. It’s easier to make backups, portable (which is usually required when you pass it to some people for translation) and could even be replaced after the application / game has been build if you load it from an external source. If you don’t want to have it external you can still use a TextAsset which will be embedded in your project. XML is probably the most used and versatile format, but the XML library is quite large. JSON would be another alternaitve. Of course a simple CSV file would work as well.