Add multiply headers to the request can lead performance problem

[ikhvostenkov]

Now to add multiply headers to the request, we need code like this:

req = new RqWithHeader(req, "X-Takes-LocalAddress",
            socket.getLocalAddress().toString());
req = new RqWithHeader(req, "X-Takes-LocalPort",
            Integer.toString(socket.getLocalPort()));

If you need to add some amount of headers on a high load such code will fail due to big amount of objects.

Will be better to add headers in RqWithHeader as a map or something similar.

[yegor256]

@ikhvostenkov have you ever seen any code failing due to "big amount of objects"?

[ikhvostenkov]

@yegor256 I saw. You will get GC every 10ms and application will 95% of the time doing garbage collection. This applicable to the high loads not to the 3 users. http://openjdk.java.net/jeps/169

[yegor256]

@ikhvostenkov the entire Takes framework is based on the idea of "many micro objects is better than few big objects"... I'm not sure this situation you just mentioned is reproducible in case of Takes. We should create some performance tests and see how it behaves. I'm 99% sure that object creation is not a bottleneck.

[ikhvostenkov]

@yegor256 Yes, I agree without performance tests and performance requirements make no sense, but we can calculate approximately. If you want to add 10 headers - 10 objects RqWithHeader + 10 objects of the internal class, which is created inside constructor. Header object is minimum 12 bytes - all 240 bytes + RqWithHeader contains link to object Request - this is 4x10=40 bytes in total 240+40=280 bytes. For the 1M of requests this is 280MB and this is only headers.

[yegor256]

@ikhvostenkov would you be interested to create an automated integration test and prove this theory?

[ikhvostenkov]

@yegor256 yes, why not. Do you plan to do performance tests for whole framework?

[yegor256]

@ikhvostenkov yes, would be great to do them, I just don't know exactly how... in an automated way.

[exper0]

@ikhvostenkov @yegor256 interesting discussion. For sure having too much object can be a problem, I also saw cases when it's a problem (GC time is about 40%-60% or more of all CPU time). However, following should be taken into account:

1. Performance requirements or actual/planned load (already mentioned)
2. The amount of memory available for the application. Having very big reserve of free heap space will make the number of objects not very important (though stop-the-world problem is still possible).

Generally, it's a classic tradeoff between performance and maintainability. The best way to create super fast program is to use C or even assembler - but it's much more difficult to maintain and support. However, in vast majority of cases hardware is cheaper than people and it's much easier to make application is scalable(and add hardware resources) compare to doing micro optimizations

[yegor256]

@exper0 yes, you're right, but we still need to try to make our framework as fast as it's possible in JVM