Performance question

[Jordi]

Hello.

I am building a client-server application.
I need to send and receive information in both sides, and do some
computing with it in both sides.

So I will build a custom protocol for that.
I have these options:

1) Send and receive objects that contain the info.
2) Send text, and cut it in pieces that will be stored in a temporal
object so I can deal with the information easier. Then destroy the
object after that.
3) Deal all time with text. This may make the code very complex.

Basically, some people told me that solytion 1 can make some loose of
performance, as text is faster to transmit than objects.
The solution 3 can be a pain, but I am not very worried, as I will be
the only one that reads my code.

I think 2 is the best, as I will be able to transmit info fast and
will use a temporal object just to handle easy the information.

All time I will send and receive byte arrays by NIO.

My question has to deal about knowing if I loose bandwith or CPU
cycles more or less if I do 1, 2 or 3.

Thanks for any advice.

Jordi

 

[Joshua Cranmer]

Hello.

I am building a client-server application.
I need to send and receive information in both sides, and do some
computing with it in both sides.

So I will build a custom protocol for that.
I have these options:

1) Send and receive objects that contain the info.
2) Send text, and cut it in pieces that will be stored in a temporal
object so I can deal with the information easier. Then destroy the
object after that.
3) Deal all time with text. This may make the code very complex.

Basically, some people told me that solytion 1 can make some loose of
performance, as text is faster to transmit than objects.
The solution 3 can be a pain, but I am not very worried, as I will be
the only one that reads my code.

I think 2 is the best, as I will be able to transmit info fast and
will use a temporal object just to handle easy the information.

All time I will send and receive byte arrays by NIO.

My question has to deal about knowing if I loose bandwith or CPU
cycles more or less if I do 1, 2 or 3.

Thanks for any advice.

Jordi

At a low enough level, #1 and #2 are identical. I don't exactly know how
Java handles the sending of objects, but I would assume that it would be
along the lines of sending some uid and then serialized data.

The best option is probably to do #2, although if you are (for example)
sending numbers, it would probably be better to use binary instead of text.

There are two things to say about optimization. First, it probably does
not matter 90% of the time. Second, try all the feasible options and
then profile to figure out which is the fastest. Intuitively, number 3
is probably the slowest; options 1 and 2 are probably about as equally fast.

 

[Martin Gregorie]

Hello.

I am building a client-server application.
I need to send and receive information in both sides, and do some
computing with it in both sides.

So I will build a custom protocol for that.
I have these options:

1) Send and receive objects that contain the info.
2) Send text, and cut it in pieces that will be stored in a temporal
object so I can deal with the information easier. Then destroy the
object after that.
3) Deal all time with text. This may make the code very complex.

Basically, some people told me that solytion 1 can make some loose of
performance, as text is faster to transmit than objects.
The solution 3 can be a pain, but I am not very worried, as I will be
the only one that reads my code.

I think 2 is the best, as I will be able to transmit info fast and
will use a temporal object just to handle easy the information.

Yes, agreed. Besides, debugging is easier if the message is plain
printable ASCII if at all possible, Think about the message design to
ensure its simple to parse and to determine when you've read the whole
message, something like:

- fixed length command/ID
- length of the rest of the message (fixed length ASCII field)
- csv message body, format dependent on the command

Designing the message protocol so that every message is acknowledged by
one response makes for easy implementation and vastly simplifies
debugging while adding very little overhead if the response is small.

All time I will send and receive byte arrays by NIO.

Good move.

My question has to deal about knowing if I loose bandwith or CPU
cycles more or less if I do 1, 2 or 3.

To determine that you need to know how big the object(s) are compared to
equivalent text messages, line speed, and (if its an Ethernet or
wireless network) how much contention you'll suffer from other traffic.

As networks are much slower than in-memory processing, a safe rule of
thumb is smaller transfers are best unless there is huge amounts of CPU
needed to handle each message.

Put it this way: compressing large amounts of data for transmission is
usually much faster than banging it over the network uncompressed.

HTH

 

[Robert Klemme]

I am building a client-server application.
I need to send and receive information in both sides, and do some
computing with it in both sides.

So I will build a custom protocol for that.
I have these options:

1) Send and receive objects that contain the info.
2) Send text, and cut it in pieces that will be stored in a temporal
object so I can deal with the information easier. Then destroy the
object after that.
3) Deal all time with text. This may make the code very complex.

Basically, some people told me that solytion 1 can make some loose of
performance, as text is faster to transmit than objects.
The solution 3 can be a pain, but I am not very worried, as I will be
the only one that reads my code.

I think 2 is the best, as I will be able to transmit info fast and
will use a temporal object just to handle easy the information.

All time I will send and receive byte arrays by NIO.

Why don't you use RMI?

My question has to deal about knowing if I loose bandwith or CPU
cycles more or less if I do 1, 2 or 3.

When using binary streams or RMI, I'd use #1 as serializing and
deserializing a complex object is likely faster than parsing it yourself
from text.

Another note: if you encapsulate the communication reasonable well you
can easily change the communication means later without affecting other
code.

Having said that I'd start with the easiest (i.e. let Java do what it
can do for you) and only change it if there are performance issues with
this. It is likely though that network communication times dominate
performance and exchanging the marshalling and demarshalling code
doesn't make a significant difference.

Kind regards

robert

 

[Jordi]

Thanks Johsua, Robert and Martin.

I think I will try to use NIO and send my custom objects, each one
being a type of message.
But maybe I will be forced to use text, and use option 2 as there is
no documentation about sending objects through NIO converted to byte
streams, so they remain not blocking.

I don't use RMI because I think NIO can be faster, and I have no idea
of RMI.

Thanks for all the ideas.
I will explain a bit more, so if you can give me some advice more, I
will appreciate.

The application is a kind of chat with 3d. I need to send some data,
but no complex data.
Just messages that strat an animation, or a color data, or a position.
And of course, wich was the sender.

So the class that encapsulates that data will be small, with few
properties and basically: function-sender-type-value

Most of this data will be integer, text or small float values.

Do you think it would be good to send it as object?
I think it doesn't matter if I send it as object or text, it seems, as
it is really simple data.

Will the data use the same size/bandwith if it is send as String or
char array as it was send as object? How could I measure that?

Thanks

Jordi

 

[Robert Klemme]

Thanks Johsua, Robert and Martin.

I think I will try to use NIO and send my custom objects, each one
being a type of message.
But maybe I will be forced to use text, and use option 2 as there is
no documentation about sending objects through NIO converted to byte
streams, so they remain not blocking.

I don't use RMI because I think NIO can be faster, and I have no idea
of RMI.

This smells like premature optimization. Granted, RMI might not be easy
to set up the first time but it is much easier to add more methods /
messages etc. So *I* would definitively prefer RMI over something
homegrown.

Thanks for all the ideas.
I will explain a bit more, so if you can give me some advice more, I
will appreciate.

The application is a kind of chat with 3d. I need to send some data,
but no complex data.
Just messages that strat an animation, or a color data, or a position.
And of course, wich was the sender.

So the class that encapsulates that data will be small, with few
properties and basically: function-sender-type-value

Most of this data will be integer, text or small float values.

Do you think it would be good to send it as object?
I think it doesn't matter if I send it as object or text, it seems, as
it is really simple data.

Will the data use the same size/bandwith if it is send as String or
char array as it was send as object? How could I measure that?

You can serialize it using a ByteArraOutputStream as output stream and
look at the resulting byte array size.

Regards

robert

 

[Jordi]

Thanks Robert

But I will use NIO anyway as it doesn't uses threads as I read it does
RMI.
I really need to have as many clients as possible connected.

I will try to measure the size of the objects sent, as you said.

The person that is helping me with NIO and objects says sending
objects may be a bit heavier but with NIO the difference is minimal.

Thanks for all the replies.

If someone has any comments more about sending objects or text, is
welcome.

Thanks again.

Jordi