Nice, hope the code is prettier than your speech. :D On Fri, Feb 14, 2014 at 12:56 AM, Orvid King <blah38621@gmail.com> wrote: > Well, I wrote the code for this a while back, and although it was > originally intended as a replacement for just std.json (thus the repo > name), it does have the framework in place to be a generalized > serialization framework, and there is the start of xml, and bson > implementations, so I'm releasing it as std.serialization. The JSON > implementation is the only one I'd consider ready for production use > however. The (de)serialization framework takes a step back and asks, "Why > do we need pull parsers?", the answer to which is that allocations are > slow, so don't allocate. And that's exactly what I do. The serializer does > absolutely *no* allocations of it's own (except for float->string > conversion, which I don't understand the algorithms enough to implement > myself) even going so far as to create an output range based version of > to!string(int/ uint/ long/ulong/ etc.). And the benefits of doing it this > way are very clearly reflected in the pure speed of the serializer. On my > 2ghz i5 Macbook Air, it takes 50ms to serialize 100k objects with roughly > 600k integers contained in them when compiled with DMD, this roughly half > the time it takes to generate the data to serialize. Compile it with GDC or > LDC and that time is cut in half. I have done the exact same thing with > deserialization as well, the only allocations done are for the output > objects, because there is no intermediate representation. > > So how do I use this greatness? Simple! import std.serialization, and apply the @serializable UDA to the class/struct you want to serialize, then call toJOSN(yourObject) and fromJSON!YourType(yourString) to your heart's content! > > Now, there are other serialization libraries out there, such as orange, that take the compile-time reflection approach, but the amount of code required to implement a single format is just massive 2100 lines for the XMLArchive. The entire JSON (de)serialization, which *includes* both the lexer and parser is only 900 lines. > > > > > Wow, that went a bit more towards a salesman-like description than I as aiming for, so I'll just end this here and give you the link, before this ends up looking like a massive, badly written, sales pitch :D > > https:// github.com/ Orvid/ JSONSeri alization > Well, I wrote the code for this a while back, and although it wasoriginally intended as a replacement for just std.json (thus the reponame), it does have the framework in place to be a generalizedserialization framework, and there is the start of xml, and bsonimplementations, so I'm releasing it as std.serialization. The JSONimplementation is the only one I'd consider ready for production usehowever. The (de)serialization framework takes a step back and asks, "Whydo we need pull parsers?", the answer to which is that allocations areslow, so don't allocate. And that's exactly what I do. The serializer doesabsolutely *no* allocations of it's own (except for float->stringconversion, which I don't understand the algorithms enough to implementmyself) even going so far as to create an output range based version ofAnd the benefits of doing it thisway are very clearly reflected in the pure speed of the serializer. On my2ghz i5 Macbook Air, it takes 50ms to serialize 100k objects with roughly600k integers contained in them when compiled with DMD, this roughly halfthe time it takes to generate the data to serialize. Compile it with GDC orLDC and that time is cut in half. I have done the exact same thing withdeserialization as well, the only allocations done are for the outputobjects, because there is no intermediate representation.So how do I use this greatness? Simple! import std.serialization, and apply the @serializable UDA to the class/struct you want to serialize, then call toJOSN(yourObject) and fromJSON!YourType(yourString) to your heart's content!Now, there are other serialization libraries out there, such as orange, that take the compile-time reflection approach, but the amount of code required to implement a single format is just massive 2100 lines for the XMLArchive. The entire JSON (de)serialization, which *includes* both the lexer and parser is only 900 lines.Wow, that went a bit more towards a salesman-like description than I as aiming for, so I'll just end this here and give you the link, before this ends up looking like a massive, badly written, sales pitch :D