Syntec Interestingly I would expect the deserialize function to take longer as it involves string parsing
For all my nattering about string performance, despite that the .NET strings backing everything are immutable and only appear to be mutable, I agree ... you need truly HOT paths for it to become an issue and even then you have to be careful not to add overhead going to and from the code point domain. I am refining a MutableString class that I think is useful in those situations but on the basis that "premature optimization is the root of all evil" (Knuth, IIRC), I'm still very judicious in using it. MutableString can fill the office of .NET's StringBuilder but can go much further, performing many string manipulations in the code point domain if you happen to be there anyhow. But you still have to benchmark against "normal" direct string manipulation and the tradeoffs aren't always intuitive.
I think some of this is because a lot of the guidance on string manipulation comes from .NET 1.x and 2.x and an awful lot of optimization has happened since in .NET and Objo benefits from that. On some level, I wish we had chars and Spans to help with certain string manipulations as it offends my sensibilities to have Int64s and MemoryBlocks standing in for them, but Objo's architecture with its memory slots kind of renders that moot anyway; it's not as simple as trimming a few bytes here and there. I have come to see it from Garry's perspective mostly -- don't add types willy-nilly unless there's a demonstrable need grounded in real world experience. Keep it clean and simple and make good architectural choices.
Similarly I'd welcome AOT builds and the like down the road someplace because I am always reflexively looking over my shoulder on the performance front. I'm not immune to the subjective charms of native code compilers producing teensy executables. It's just that those charms are just what I said: subjective. We're long past the world of 110ms response times on hard drive seeks physically connected with 50-pin flat cables, with their own power supplies, and brighter minds than mine have long applied themselves to every conceivable caching trick, in both hardware and software. These are the wrong things to be over-focusing on here in the year 2026.
So -- to borrow from Dr Strangelove -- what if you just quit worrying and loved the abstraction? All it has to do to be successful is get the job done from the end user's perspective without getting in the way of the developer by making their exertions unpleasant, and without hogging system resources enough to influence the responsiveness of other processes.
It's just that living in the .NET world for a long time and coming ultimately from the 8 bit world of bank-switched RAM in 32K chunks, I've developed a certain approach with a set of background caveats based on a certain set of assumptions and tradeoffs. But the combination of Objo and modern hardware advances frees me up to focus on the actual problem domain, which is not bits and bytes but functionality for the user. Increasingly I am willing to roll with it because it Just Works and I have more and more respect for Garry's architectural instincts in this realm.
The delicious part of this is that if Objo's competitors are reduced to "yabuts" -- yeah, but it's not native code, yeah, but it's a scary custom VM, yeah, but it's -- it's -- it's NEW TO ME! Well -- if that's all they got, it's a good thing, IMO.
All that said, I am a curious person and I enjoy understanding the internals and pushing the boundaries of what's possible ... also I understand political realities. So, when I can ask for a common need to be moved internal to the VM rather than remain in Objo code, and Garry generally will do it within reason, then I think we have the best of both worlds and Objo can better be seen as technologically sophisticated and carefully optimized.