Done. On Sun, Oct 17, 2010 at 12:30 AM, Sean Owen <[email protected]> wrote:
> Tough call. It's arguably so inefficient as to be thought of as a mild bug. > There's also some value in not letting the existing serialization bake in > to > users' infrastructure for another 6 months. I am not concerned with > backward > compatibility of this magnitude at this stage, myself. > > Therefore if this bit is well-tested, and those tests pass, I say add your > change now. > > On Sun, Oct 17, 2010 at 5:51 AM, Ted Dunning <[email protected]> > wrote: > > > I just noticed that our matrix json serialization has a strangeness in > it. > > The issue is that a matrix is serialized as an object with two > properties. > > > > The first property is the class name of the actual matrix. > > > > The second property is the serialized form of the matrix. Unfortunately, > > this serialized form is stored as a JSON string rather than a JSON > object. > > This means that we wind up parsing matrix objects multiple times, first > as > > the object, then extracting the string, parsing that, then possibly > > extracting rows as objects which contain strings which must be parsed. > > JSON > > parsing is fast, but this is perverse. > > > > I am happy to fix this along with all tests that break (shouldn't be > any). > > I would very much like to fix this for 0.4, but it could wait. > > > > Is there anybody who depends on archival storage of JSON serialized > > matrices > > or vectors? I think I can make the format backward compatible, but would > > still like to know. > > >
