Why not jiffy? about sockjs-erlang HOT 8 CLOSED

I dunno, ignorance? For me it doesn't show up in the first 10 pages searching for "erlang json" so it might as well not exist ;-)

Sarcasm aside, we already support eep0018 so jiffy should not be a stretch.

from sockjs-erlang.

(FTR: jiffy lives here https://github.com/davisp/jiffy)

Also: [...] premature optimization [...]

I think we should make SockJS stable first and than play with not-pure-erlang dependencies.

Additionally, there are high chances that JSON encoding will not be used for SockJS-protocol v0.2.

from sockjs-erlang.

(Of course we can revisit this if the new protocol still needs JSON...)

from sockjs-erlang.

In #9 we came back to the idea.

from sockjs-erlang.

Nice to hear.

from sockjs-erlang.

It seems that it won't be a premature optimization. Here's the output of fprof analysis over application which does broadcast data to ~3000 users 4 times (short messages around 110-120 bytes each, excluding SockJS protocol overhead):

https://gist.github.com/2781872

As you can see mochijson2 and it's utf8 handling code is the most CPU hungry one.

from sockjs-erlang.

http://si14.livejournal.com/18757.html you can also find some JSON-related benchmarks here.

from sockjs-erlang.

@gleber Jiffy is fine. We actually did support it in previous sockjs-erlang versions:

• sockjs-erlang/src/sockjs_util.erl

  Line 36 in fb32ebb

  jiffy(Thing, encode) ->

But, SockJS requires custom encoding of some unicode characters. Mochiweb does most of the work out of the box and to get everything working (\uFFFE and \uFFFF chars) I needed to patch it a bit.

I'm happy to have optional jiffy support if it passes all the sockjs-protocol tests regarding encoding:

• http://sockjs.github.com/sockjs-protocol/sockjs-protocol-0.3.html#section-129

from sockjs-erlang.