Json vs XML vs Java Serializable

For multiplayer better to use XML, Json or Serializable?
SpiderMonkey use serializable, but the same issue can solve Json or Xml. Are any performance by using SpiderMokey?
For example, XML has schemas which helps to have less bags, or Json has small size.

For (game) network, json or xml (or any text based encoding) is the less performant choice.

see Home · eishay/jvm-serializers Wiki · GitHub

Thank you.

Yeah, XML is the WORST for performance networking. JSON second worst.

…I’m really not even sure why we are having this discussion, actually… but… :smile:

Take this message:

public class MyMessage {
    private int someField;
    private int someOtherField;
   ....
}

In XML, if I’m being generous and assume you will at least use attributes and no extra whitespace:

<MyMessage someField="123456789" someOtherField="1234567890"/>

So, to send that you need a length and the characters… UTF-8 at least means one byte per character. And I’ll be generous and pretend you already know your message size will fit in a short.
2 bytes + 62 bytes = 64 bytes to send that data.

Maybe for json it would look like:

{"MyMessage":{"myField":123456789,"myOtherField":1234567890}}

2 bytes + 61 bytes = 63 bytes

Actually, so json is not much better but I think would save a few more bytes over time.

In SpiderMonkey, the message only takes 2 + 2 + 4 + 4 bytes… 12 bytes. And the savings gets even better as you add more fields and potential subtypes.

5 Likes

I agree with everything, however to put things in perspective I’d like to remind that the network packet you are sending still includes the header padding; and if you are using TCP you are sending a few extra Kb for handshake and the like.

So, if you manage 2 network hosts, possibly on a LAN, and you have other reasons for preferring XML, sending 12 bytes or 64 bytes won’t make much difference.

Totally agree with @pspeed, don’t even bother with XML or JSON for really high performance networking, especially in games. Even if the data size would be acceptable to you, you still have to convert the text to and from XML and JSON which is also very expensive.

As an alternative to SpiderMonkey it could also be worth checking out Kryonet which uses a similar API and uses Kryo as the underlying serialization engine.

But then you have to go through all of the to/from string conversion, etc… Plus you’d have to write all of that code or (ugh) use JAXB.

Also, this is a simple example. For every field or subtype added, the XML size will go up exponentially while the SpiderMonkey size will go up only by the data size.

Let’s take another example:

public final class MySubType {
    String name;
    int age;
    boolean coolGuy;
}

public class MyMessage {
    private int someField;
    private int someOtherField;
    private MySubType info;
...
}

So, XML might look like:

<MyMessage someField="123456789" someOtherField="1234567890"><info><MySubType name="John Doe" age="42" coolGuy="true"/></info></MyMessage>

2 + 139 = 141 bytes

Now in SpiderMonkey, that’s going to be:
2 (msg size) + 2 (class ID) + 4 (someField value) + 4 (someOtherField value) + 1 (string size) + 8 (string contents) + 4 (age field) + 1 (boolean field)
= 26 bytes

That’s the entire size of the message other than TCP/IP overhead. And if you are sending messages through UDP, the smaller they are, the more likely they will get through.

I’m not sure why one would want to go through the trouble of converting stuff to/from XML themselves when they can just have real messages and let SpiderMonkey autowire it with a single call.

Not sure what Kryonet serialization offers over SpiderMonkey… since I’m pretty sure the original author of SpiderMonkey just copied Kryonet originally.

I’d like to think we have a nicer API overall… but I’m biased. :slight_smile: (Though the serialization is one thing I’d like to redo based on bit streams.)

I do agree with you in everything, but OP clears your doubts:

I just add that XML has its own authoring tools and ecosystem; it is possible that for some reason somebody prefer to use it. Just speculating, I have no facts to support my arguments.

Sure… but if we follow the logic train then it breaks down pretty quickly…

At some point this data will have to be used by the app. If the app is going directly to the XML for that then there a bunch of chances for “bags” regardless of schema. If it is not going directly to the XML for that then it is converting them to Java somehow… in which case the Java classes are the best schema you will need and 0 chance for “bags”… even less than for XML.

So my guess is that the performance implications just weren’t understood by the OP.

1 Like

Somebody use java externalizable?

Even still, the overhead from standard Java serialization is fairly high… even for externalizable.

Why is it that you want to avoid SpiderMonkey’s serializer so badly?

I want to know all possibilities, at the moment my choice is SpiderMonkey.

I’m barely above clueless about networking and bytes and stuff. I used spidermonkey and it was a delight to use.
Performances were great, learning curve was near flat and separation was very clean, and never had to think about a special case… all were immediately resolved. 11/10.

I use a own serializer kinda similar to spidermonkey, (just older than it) and it performs fine,
I also infact use a Json based message system for the ingame computers, as for them performance implications are simply offloaded into their performance, and it reduces problems with programming errors causing low level faults in the networking.