Vanilla Java

Overview Chronicle FIX is our Low Latency FIX engine and database for Java. What makes it different is that it; is designed for ultra low GC* in Java. supports Strings and date times in a way which minimises garbage and overhead. is customisable to include only the fields you expect. uses optimisations normally used in binary parsers and generators such as reading/writing 4 or 8 bytes at a time to improve efficiency. built on low latency persistence to minimise the latency of logging. is optimised for low latency network cards such as Solarflare. * Ultra low GC means it can produce less than a byte of garbage per message on average If you keep your total garbage rate to less than 1 GB per hour a 24 GB Eden can take all day to fill up and you don't get any minor GCs.  Produce less than 200 MB/hour and you can run for a week without a GC. But isn't Java slow? Java can be slower than C++ but written well Java can be faster than a C++ application not writte

Overview Operator overloading is available in an number of languages.  Java has very limited operator overloading in it's support for the + operator for String types. We can draw on the different ways other languages support operators, however could we have an implementation in Java which uses conventions Java already uses. Get, set and put operations A common example of operator overloading for collections is using the array notation a[b] to access the collection itself.  When getting this is straight forward as both List and Map have a get method and this is consistent with the JavaBean getXxx() naming convention. List<String> text = ... String s = text[2]; // text.get(2); Map<String, MyType> map = ... MyType mt = map["Hello"]; // map.get("Hello") MyType mt = ... String xxx = ... String s = mt[xxx]; // mt.getXxx(); When it comes to setting a value based on an index or key, we have List.set(), Map.put() and setXxx() fr

Overview The strategy that's used for hashing keys, can have a direct impact on the performance of a hashed collections such as a HashMap or HashSet. The built-in hashing functions are designed to be generic and work well in a wide range of use cases.  Can we do better, especially if you have a good idea of the use case? Testing a hashing strategy In a previous article I looked at a number of ways to test hashing strategies and in particular looked at a hashing strategy which had been optimised for "Orthogonal Bits" which looked at making sure each hash result was as different as possible based on just one bit changing. However, if you have a known set of elements/keys to hash you can optimise for that specific use case, rather trying to find a generic solution. Minimising Collisions One of the main things you want to avoid in a hashed collection is collisions.  This is when two or more keys map to the same bucket.  These collisions mean you have to do more

Overview The way to make any data structure or algorithm as fast as possible is for the code to do exactly what you want and no more.  The problem with building a data store which does everything anyone could want is that it won't do anything particularly well. What can you achieve with a custom data store in terms of performance? You can support; read/write latencies of around 75 nano-seconds. throughputs of 40 million operations per second. with binary encoding and compression reduce the size of your data by a factor of 100 or more. This saves memory and increases scalability. Control how replication utilises your network, or is synchronized with your database. Chronicle Map and Queue are very efficient, however if they don't do exactly what you need or they do more than you need this sort of collection has the potential to be much faster. Optimise the hash function for a known, fairly stable key set to minimise collision rate. Do we really need a customiz

Half priced Gold support For the month of September 2015 we are offering Gold Support for half price. This includes Chronicle open source software. Core Java Development Any number of environments, server or client. Up to 2.5 days per month. Including ad hoc consulting and bespoke development. Email, JIRA or emergency phone support, 24/7, 2 hour response target. For the support and development alone, that's up to 30 days for as little as £700/day or $1100/day. If you would like to know more, please contact sales@chronicle.software