Invoke in-editor serialization automatically when member value changes

[vexe]

Unitys sends tons of serialization messages responding to/serializing in all of them causes huge editor lag on my machine (using FullSerializer).

The way to identify if a member in a target has changed is tricky. The only decent way of doing it was to actually serialize the member value and compare the resulting data with the target current data (see RuntimeHelper.IsModified) - but that doesn't really solve the issue since it's using serialization to detect the change, and determine whether or not we should serialize... Frankly, this sound stupid. But I had to do it since some System.Object references were losing their values when serializing in every Unity serialization message.

In a recent commit I introduced the ability (OPTIONAL, turned off by default) to manually mark an object changed/dirty and only then serialize it (https://github.com/vexe/VFW/commit/6344fc466dc0b24b9912a2556a600aea0c3c5ffe) - I was calling MarkChanged when the gui changes, but that soon appeared to be a very bad idea, imagine typing in a search box filtering a huge collection and every time you type a letter the collection serializes generating 10s of MB garbage (eventually it reached 100MB).... But now it's a pain in the back to have to track down when a member changes to call MarkChanged. You pretty much have to always remember to mark if you're modifying the member from code, not via editor.

It would really be nice if there was a way to invoke serialization only when needed. that might include:

• When a member in a target changes value (either from editor or code)
• OR only when you enter playmode, close Unity and switch scene

[colms]

I actually love these author issues because they give insight into the framework and they let people know what's on the development road map.

[vexe]

I could not find an ideal solution to the problem. FullSerializer is low but is the most convenient. The other serializers I wrote (binary) are still not mature yet, I change the data layout from time to time, that is not a good thing to do in a serializer exposed to the public in a framework.

The best solution I found is just to use BaseBehaviour https://github.com/vexe/VFW/commit/f1a52d87c03e8acd51c2eb14fd3501015dd75285 wherever possible (has 0 runtime penalty) and just stick to Unity's serialization, and workaround it if you need to (e.g. SerializableDictionary https://github.com/vexe/VFW/commit/1712456a6ff22073435c4b35e2a972bf31bd7d04) Custom serialization is either slow, or not robust/stable.

Although we give Unity's serialization flak, but it's actually pretty good for what it is. The limitations are not so bad to work with. Who needs to serialize public auto-propertie? just use fields.. I never needed polymorphic serialization in my game, in fact I think OOP/inheritance is one of the worst designs you could use in a game, it drastically over-complicates things and brings focus away from the real problem: data. Maybe I'll rant about this later.