OpenBook Ultra just added a field to their feed where the timestamps are in microseconds. When I say HF, I mean trading where that precision on time stamps makes a difference. Most options MMs are still playing games on the millisecond scale, but the stock MMs and cross-market arbitrage people are running around paranoid about microseconds -- at least, the serious ones are. I hear from a lot of jokers about being HF trading at 40-50ms lags and I just don't take them seriously. The BATS exchange also is so aggressive as its press releases brag about 200microsecond reductions on database transactions. The king in the space of speed seems to be GETCO. I knew where they were 5 years ago, but I don't know what they're rocking in terms of performance today. My understanding is that GETCO owns part of BATS, which explains a lot about why that ECN is so high-quality. C++ doesn't call brk() either. It only calls brk() when the memory allocated for the heap is exhausted. Of course, a bad implementation could call brk(), but it really depends on the efficiency of your libc implementation, since new is effectively a wrapper for C's malloc(). Java new is probably more efficient on the general case because it makes use of run-time type information. I imagine they've worked into their scheme some means of recognizing what just got garbage collected. If the garbage collector has some sort of intelligent algorithm for detecting the cyclic need for objects, it may just save a chunk of memory for re-use later. Java is not appropriate for microsecond-level HF trading, at least not without doing a portion of the work with JNI and changing garbage collection policies. In C++, unless new and delete are overloaded, it's essentially a generic memory grab over top of a brk()'d piece of memory and construction on top of that memory. You can overload the allocators and get Java-style behavior, though. Depends on how motivated you are. Same goes for STL and custom allocators.