Open amnaredo opened 3 years ago
Can't you just convert them back and forth? I bet it'd be like 10 lines of code each way, so maybe 20 total. uPickle doesn't even need to care.
Original Author: lihaoyi
Definitely true, although I suppose direct implementation would be better for performance reasons?
Original Author: mdedetrich
Have you profiled it? =P I'm probably not going to make major changes to the library (and take on icky dependencies!) just on a supposition... the JVM is surprisingly fast
Original Author: lihaoyi
Ok cool, will just do manual conversions and Ill do some performance benchmarks to see if there is a big difference
Original Author: mdedetrich
Make sure you use macro-benchmarks and not micro-benchmarks. Maybe it'll be 2x faster to deserialize the JSON, and 1.007x faster to "perform some action" in your system...
Original Author: lihaoyi
I expect the difference would be largest when you serialise massive JSON data structures, as opposed to smaller ones.
Although its true that the macro benchmark may be more "relevant", what your system is relative (we have cases where we deal with JSON that is megabytes in size, and in that sense, micro benchmarks do matter).
Note that its not that hard to decouple uPickle from the underlying AST, something like https://github.com/json4s/muster already does it really well (reason why I am looking at uPickle is that muster has been abandoned, and I do need something that is fast)
Original Author: mdedetrich
Was wondering how difficult it would be for uPickle to support alternative AST's (such as Json4s which is what I personally use). I mention Json4s, since its API is written in pure Scala.
Would love to use uPickle, but it only supports Jawn (and all of our JSON handling code uses Json4s). Note that Jawn itself does support other AST's, so not sure if this is helpful
ID: 53 Original Author: mdedetrich