Closed GoogleCodeExporter closed 8 years ago
I thought JsvReader was a .NET class, now I realize it is a ServiceStack's
class, and
.NET has no bugs.
Original comment by jad...@gmail.com
on 28 May 2010 at 3:11
Can someone edit my post to correct this?
Original comment by jad...@gmail.com
on 28 May 2010 at 3:12
Hi jaderd,
I've just seen the issue now. Looks like I didn't think to escape floating
point numbers since I always assumed
'.' like a proper westerner :)
Anyway I'll try get onto a fix this weekend. I'll let you know on this thread
when its done.
Unfortunately the admin UI here only lets me delete the last 2 comments you've
sent and cannot edit the
original issue. I don't think there's anything to worry about as it a natural
misunderstanding that anyone
could make.
Original comment by demis.be...@gmail.com
on 28 May 2010 at 3:55
Thanks for your time demis.
I see that JsvSerializer is very close to JavascriptSerializer, but I belive
your team
had reasons to implement such class. The default behavior of
JavascriptSerializer is to
serialize everything using CultureInfo.InvariantCulture, and parse it using the
same
culture. I don't think you should escape numbers.
I also would like to point that pt-BR is also a western culture, besides using
a
different decimal separator.
Original comment by jad...@gmail.com
on 28 May 2010 at 4:38
The main reason for inventing Jsv format is because existing Json serializers
in .NET were too slow.
More detail about the reasoning and benefits behind the new format are
available at: http://www.servicestack.net/mythz_blog/?p=176
JavascriptSerializer is the slowest of all. I've got benchmarks showing it over
240x slower than protobuf (basically don't ever use it), if
you want a JSON serializer I recommend that you use JsonDataContractSerializer
or James Newton JSON.NET's serializer.
Ok thanks for the tip of using InvarantCulture - definitely the way to go so
your serialized data can be deserializable from anywhere. Will
implement the fix with this approach.
Original comment by demis.be...@gmail.com
on 28 May 2010 at 5:13
I liked your Jsv format. I wonder if your implementation could be modified to
generate
JSON/Javascript as fast as it does Jsv.
Original comment by jad...@gmail.com
on 30 May 2010 at 8:34
Wouldn't JSV be more compact if it used double commas (,, replacing single
commas)
instead of double quotes (" at the end and the beggining of a string) to escape
strings
?
(I know it's too late to change that)
Original comment by jad...@gmail.com
on 30 May 2010 at 8:38
Hey jaderd,
Yeah I think it's possible to port the 'JSV' approach to a JSON format and get
a lot better perf than what is currently available. It
won't be as fast (the format does help) but I'd imagine should still be within
a comparable range. @marcgravell from
http://code.google.com/p/protobuf-net/ has hinted that after his v2 rewrite
that he might be interested in re-using his tech and
consider implementing a JSON format. If he does that should end up being the
fastest possible implementation since its mostly custom
Reflection emitted and avoids all type casts.
I'm in no hurry since there are a few options available and will wait to see
what @marcgravell decides what he's going to do. Either
that or hopefully Microsoft's lifts their game and ships a better serializer :)
As for the ",," that would be a good approach if the only thing I had to escape
was commas. Unfortunately to remain lexically parse-
able I have to escape all special chars i.e. []{},". Also having it use
CSV-style escaping means that it would be trivially possible
to re-project an array of JSV objects into a CSV dataset without any
de-serialization.
Original comment by demis.be...@gmail.com
on 30 May 2010 at 9:06
thank you for your explanation
Original comment by jad...@gmail.com
on 30 May 2010 at 9:51
Hi jaderd,
Sorry for the delay, spent some time away from the computer to enjoy the long
weekend :)
I've released a new version of all ServiceStack binary releases to 1.31 which
should include the latest fixes.
Let me know if it works for you so I can close this ticket.
Cheers,
Demis
Original comment by demis.be...@gmail.com
on 2 Jun 2010 at 1:32
Hi Demis,
I tried to test, but then I realized that since I migrated from Redis to
Memcached I'm
not using Jsv anymore. I was investigating why and I found that your
MemcachedClient is
just an interface to Enyim's.
Do you plan to implement a MemcachedClient that uses Jsv instead of the default
serializers?
Original comment by jad...@gmail.com
on 2 Jun 2010 at 6:44
Hi jaderd,
Ok fine no problem. Since memcached is more a 'cache' then a 'persistence
store' it probably makes sense to use either
the most 'optimal serialization format' (protocol buffers) or the final 'output
serialization format'. E.g. with a
cache you do not expect to inspect, manipulate or version the content so you
should optimize for your use case.
For the most optimal format I would consider looking at protocol buffers, again
@marcgravell he has an adapter that
lets you use memcached configured with his protobuf-net library here:
http://marcgravell.blogspot.com/2010/01/distributed-caching-with-protobuf-net.ht
ml
Although in most cases what would be faster is to use the 'output serialization
format', if its a web page that would
mean the html, and for a web service either JSON or XML. This would be faster
because no deserialization would be
required at all and you can write the payload directly to the response stream.
Also depending on the size of the
payload you may also want to consider using the web standard deflate/gzip
compression.
Original comment by demis.be...@gmail.com
on 2 Jun 2010 at 7:01
Hi Demis,
Thank you for your exhaustive (in a good sense) explanation again. I understand now
your reasoning, and as you might have guessed I'm not using memcached for
caching :).
I'll look into marcgravell library.
Original comment by jad...@gmail.com
on 2 Jun 2010 at 11:54
Original comment by demis.be...@gmail.com
on 2 Jun 2010 at 11:58
Original issue reported on code.google.com by
jad...@gmail.com
on 28 May 2010 at 3:07