Vanilla Java

Overview There are a number of articles on whether synchronized or Locks are faster. There appear to be opinions in favour of either option. In this article I attempt to show how you can achieve different views depending on how you benchmark the two approaches. I have included AtomicInteger to see how a volatile field compares. What are some of the differences The synchronized keyword has naturally built in language support. This can mean the JIT can optimise synchronised blocks in ways it cannot with Locks. e.g. it can combine synchronized blocks. The Lock has additional method such as tryLock which is not an option for a synchronized block. The test As the JIT can optimise synchronized in ways a Lock cannot, I wanted to have a test which might demonstrate this and one which might "fool" the JIT. In this test, 25 million locks were performed between each of the threads. Java 6 update 26 was used. Threads 1x synch 1x Lock 1x AtomicInteger 2x synch 2x Lock ...

Overview There are conflicting views as to what is the best solution for high frequency trading. Part of the problem is that what is high frequency trading varies more than you might expect, another part is what is meant by faster. My View If you have a typical Java programmer and typical C++ programmer, each with a few years experience writing a typical Object Oriented Program, and you give them the same amount of time, the Java programmer is likely to have a working program earlier and will have more time to tweak the application. In this situation it is likely the Java application will be faster. IMHO. In my experience, Java performs better at C++ at detecting code which doesn't need to be done. esp micro-benchmarks which don't do anything useful. ;) If you tune Java and C++ as far as they can go given any amount of expertise and time, the C++ program will be faster. However, given limited resources and in changing environment a dynamic language will out perform. i.e....

Overview Following my article How fast are Java sockets , this article follows the same tests except for Datagrams which use UDP rather than TCP. The timings The tests are the same except Datagrams don't support busy waiting in Java 6 which hurts the Threaded Ping latency UDP Pings per second 224 K/s UDP Pings latency was 1/50/99%tile 4.1/4.2/4.7 us Threaded UDP Pings per second 131 K/s Threaded UDP Pings latency was 1/50/99%tile 9.8/11.0/33.2 us Comparison Test  Threaded  Throughput Typical latency Datagram Ping no 224 K/s  4.2 μs Socket Ping no 170 K/s  5.8 μs Datagram Ping yes 131 K/s 11.0 μs Socket Ping yes 235 K/s 8.5 μs The Code DatagramPingTest.java Related articles How fast are Java sockets Send XML over a Socket fast

Overview When you first try to printout a HashMap, the order doesn't make any sense and when you add entries, they appear to jump around. What is going on? The order of Maps The order keys should appear is not defined in many implementations. Hash map uses a hash of the key to place the key/value in a pseudo random place in the underlying store (an array) How it does this is different in different implementations. For HashMap the size of the Map is always a power of 2. For Hashtable the size grows 11, 23, 47, 95. For LinkedHashMap, the order will be the order the keys were added and for TreeMap & ConcurrentSkipList, the order is based of the Comparable.compareTo() result (asciibetical order for String) For Hashtable and HashMap changing the initial size changes how the keys are hashed and thus their order public static void main(String... args) { populate(new Hashtable ()); populate(new Hashtable (47), " (47)"); populate(new Hashtable (95), ...

Overview The have been some very good articles on the size of a map. However as a map grows, it initial size become less important and the size per entry is what matters. How are the sizes measured In these tests an int key and long values are used. This adds a small but realistic size to each entry. Size per entry of a medium sized Map The following are the size per entry in bytes. The Map has 1024 entries. Type of Map 32-bit 64-bit compressed 64-bit not compressed TIntLongHashMap 26.9 26.9 27.0 FastMap (recycled) 32.0 39.9 47.9 IdentityHashMap 48.0 56.0 80.0 ConcurrentSkipListMap 68.3 76.1 108.3 TreeMap 64.0 80.0 112.0 HashMap 64.0 80.0 112.0 SynchronizedMap 64.0 80.0 112.0 ConcurrentHashMap 65.2 81.4 114.0 Properties 68.0 84.0 120.0 Hashtable 68.0 84.0 120.0...

Overview XML parsers are designed to handle any type of XML message you can send. However if you assume the XML will always follow a specific format how fast can you make it. This follows my article on How fast are Java sockets The format For this article I have written a self contained test which sends a heartbeat request and which expect a heartbeat response. <Root timestamp="{timestamp}"><HeartbeatRequest sequence="{sequence}"/></Root> <Root timestamp="{timestamp}"><HeartbeatResponse sequence="{sequence}"/></Root> In this test, the sequence number contains the System.nanoTime(). When the client gets back the heartbeat response it can calculate the round trip time. Messages are parsed and a listener interface called. static interface EventListener { void heartbeatRequest(long timestamp, long sequenceNumber); void heartbeatResponse(long timestamp, long sequenceNumber); ...

Overview How long a request/response takes and the rate requests can be performed in a Java application depends on a number of factors. The network, the network adapter, Java Socket and TCP layer, and what your application does. Usually the last factor is your limitation. What if you wanted to test the overhead Java/TCP contributes, here is a way you can test this. Latency and throughput The Latency, in this test, is the Round Trip Time (sometimes written as RTT) This is the time between sending a request and receiving the response. This includes the delay on the client side, the transport and the delay on the server side. The Throughput is a measure of how many request/responses can be performed in a given amount of time. How long each request/response takes is not measured, and has no impact unless its really large. The Results These results are for a fast PC doing nothing but pass data back and forth over loopback. This will be one of the limiting factors to using Java ...