Monthly Archives: September 2014

How to slim down your Java

Episode 16

This article is the second part of my Java performance guide. After concentrating on how to make code fast, let’s turn to how to make code eat less memory. There are two important things to consider:

First, in modern computers, memory access time is more limiting than CPU frequency.

Second, when talking about algorithms from academic point of view, it is said, that there is a tradeoff between speed and memory. That’s of course true, however keep in mind, that memory allocation takes time, memory read/write takes time and finally garbage collection takes time. If you turn on heap status in Eclipse, you can sometimes literally see how the code is reaching 99% percent of the heap and then execution time hits the wall and things slows down a lot. GC is working hard to make things possible. If it is possible, otherwise you are getting OutOfMemoryError and you are done.


Java, wat r u doin! Java, staph…

Of course, you can increase heap space to make things happen. However you can’t do that indefinitely (unless you are Google). Although one of my PO’s said once that we shouldn’t worry because clients have unlimited memory, you should worry. Not always, and maybe not even half the time, but being reckless with memory might hit you hard in some particular cases.

Code that is memory efficient might be complicated, hard to maintain and error prone, but there are few thing you can keep in mind and use without introducing unnecessary complications. Sometimes, as I said in previous article, code that is faster or takes less memory may be even more elegant and readable.

So when to optimize size?

Again, get to know your code. Study, experiment, check out the production database (if you have access), do some statistics. If you have a collection containing all your users, check out how much user you have. If it’s a problem, look for high level solution. Perhaps you don’t need all users at one time? Maybe you can process them in batches? Maybe you can load lazily? Maybe you can construct some kind of cache?

If this approach fails, you can tweak stuff at lower level of abstraction, and that’s what we are going to discuss now.

Objects size

Object header in Java takes 12 bytes. However objects on heap are allocated in 8 bytes blocks, thus making smallest Objects take 16 bytes. Primitive sizes are:

  • byte – well, 1 byte
  • short, char – 2 bytes
  • int, float – 4 bytes
  • long, double – 8 bytes
  • Reference – 4 bytes if heap is under 32 GB with default VM settings and 8 bytes otherwise.

So if you are thinking of reducing your object size from 32 to 28 or 26 bytes, I have bad news for you. It will still take 32 bytes no matter what.

byte and short pitfall

Primitives as objects fields always take a minimum of 4 bytes. So using bytes or shorts instead of ints as fields to save memory is useless. Arrays however are dense packed, so you may use byte and short array to get some savings.

Primitives vs wrappers

Wrappers carry the Object overhead. They take at least 16 bytes, and Long and Double takes 24. Plus 4 bytes for each reference to them. If you have a lot of data, and don’t need a null value, you can use primitives instead of wrappers to save memory. For example in a User object, if you only read data from database, you can probably use long instead of Long for primary key and save 16 bytes per object. On the other hand, if you use ORM framework, you may create objects by hand and then persist them, which means that primary key will be null at some point.


  • Primitive array of length n: 16 + (1 to 8) * n depending on primitive type.
  • Objects arrays: 16 + (4 + object_size) * n on heap below 32 GB.


Each String contains a few ints, a reference to char array and the array itself. It all takes 40 + 2*n depending on number of characters. What does it mean? If you have a lot of very short Strings, you have a lot of overhead. If you have only one-letter strings, it’s probably better to use chars instead.


Now it’s getting interesting.

  • ArrayList: 40 + (4 +object_size) *n + 4 * unused_capacity
  • LinkedList: 48 + (24 + object_size)

Yes, LinkedList has 6 times more overhead per node. That’s another reason to use ArrayList instead most of the time. Array list resizes itself automatically, so it usually has some unused space. If you know that no more data will be added, you may use it’s trimToSize method to remove unnecessary overhead. Not very much, but with lots of small objects it might be visible.


  • HashMap: 56 + (32 + object_size + key_size) * n + 4 * capacity
  • LinkedHashMap: 56 + (40 + object_size + key_size) * n + 4 capacity
  • TreeMap: 56 + (40 + object_size + key_size) * n + 4 * capacity

I had a situation where there was a graph node object, that contained several eagerly initialized collections, that were empty 95% of the time. It turns out that when number of nodes went in millions, it was a serious problem. Creating collections lazily might save you some space.

By the way, Sets in Java contains Maps, so they have same size per node, with additional overhead per Set Object.


There are libraries of specialized collections, like Trove. They are optimized for memory footprint. For example THashMap takes only 8 bytes per key / value pair instead of 40 as standard HashMap

EnumMap, EnumSet – specialized collection in standard Java. As, most of the time, Enums do not have more than 32 or 64 values, Set of enums may be represented as bit mask based on int or long. It reduces a lot of overhead for MapEntry objects.

BitSet. Dense packed bit vector, that only takes, well, only 1 bit per bit or boolean value. Normal boolean in Java occupies 4 bytes if it’s a variable or 1 byte if it’s in an array.

What’s next?

Perhaps I will come back to the topic of performance. I have a new book, Java Performance The Definitive Guide added to my long reading list. I hope it will be interesting and third episode about performance will be born on this blog afterwards.

Speaking of reading list, next episode is going to be a book review. Stay tuned ;)


Leave a comment

Posted by on September 28, 2014 in Clean Code, Technology


Tags: ,

Lightning Fast Code

Entry 15, Day 51

As promised, today’s episode is going to be about low-level optimization. First, a quote.

„Premature optimization is the root of all evil”

   – Donald Knuth

Yes indeed. We all love when things go faster than slower, but deadlines are tight and working, stable software with acceptable performance is better than software which is fast but unstable or not working at all. There is no point in tuning your Java computation to take 5 milliseconds instead of 50, when you are going to wait for database query that takes 5 seconds (optimize the query, maybe?). Also, in case of web application, there will be network latency of tenths or hundreds of milliseconds. Another issue is code readability. Sometime, to run faster, the code has to be more complicated and that’s always pain in the ass…


So when to optimize?

First, get to know your API. There are many small problems, that are already solved by standard Java library. And solved well, for example using Read the rest of this entry »


Posted by on September 21, 2014 in Clean Code, Sweet Sixteen, Technology


Tags: ,

Winds of change

Entry 14, day 44

Hello again. I’ve said some time ago, that I will perform a retrospective on my own writing. Time to do that. I had this one rule, that if I do anything in the project, I will post. But I thought this through and decided, that I want this blog to be more appealing to readers and worth going back to. So I’m going to focus more on quality of writing and less on frequency and personal logging of progress in my pet project. This of course does not mean I’m going to abandon it. You will hear about BookSentry, that’s for sure, it just not going to be the main theme.

I divided the content in roughly three areas:

Enterprise technologies. More elaboration on my technology stack, perhaps some comparisons and tutorials. Also about tools I use or going to use, so tips for Eclipse, plugins for Jenkins and all the stuff around.

Clean Code and Object Oriented Design. Underrated nowadays I think but tremendously important. Java is actually where your application takes shape. Even though there are frameworks, conventions, howtos found via google in seconds etc, the ability to create good code is absolutely crucial. On high level – general architecture, on middle level – design patterns and subsystems architecture, and on low level – how to name a damn variable.

Agile/Scrum. How to get a group of people to create an amazing software. I’m not an expert Agile coach (only a certified professional scrum master ;)), but I have experience from places with Scrum and without Scrum. And I’m happy to share it with you.

New posts will probably come once or twice a week. At least I will try post at least once per week. On occasion there will be some more philosophical posts, book reviews, news or other situational stuff.

Speaking of situational stuff, I’m excited to attend the JAX conference. in London, October 14 – 15. There will be a quite detailed coverage here, hope you are curious what’s new in Java world. I am ;)

Thanks for all the visits up to date, hope you will keep coming back ;) Also big thanks for all the feedback I’ve received. I’ve learned a lot and I’m trying to apply all advices as much as possible. As a curiosity, here is the breakdown on where are you from:


In the next episode, we will talk about Java performance. Once, we did a big refactoring with my friend and we made a quite substantial piece of software run up to 500 times faster and allocate up to 20 times less memory. If you think that computers have unlimited computational power nowadays… well they don’t. Most of the time performance is not an issue, but there are case where it is. Curious? See you next time.


Leave a comment

Posted by on September 14, 2014 in News


Glimpse into the past

Entry 13, Day 37

That was a long break, huh. But I’m back here and now. Let’s talk about the Sprint Retrospective. Time to stop running, look back and think about stuff we have just done.  As The Scrum Guide says: the Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. Inspect and adapt in a never-ending cycle of project lifetime.

Retrospective unleashes hidden demons so that they can be ceremonially butchered for the greater good of Scrum Team. And in turn – the Product.

 Dr Who

Retrospective is for the Scrum Team (Dev Team + Product Owner). PO should take part, but if the dev team feels that some issues should be discussed without PO, they can ask him/her nicely to leave for some part of the Retro. Scrum Master may also be asked to leave, but this is not recommended as the SM has  the power of insight “out of the box” not being the part of the dev team. Of course it might happen that the SM is the problem, that needs to be addressed, in which case, we have some kind of deep pathology anyway.

Any Scrum meeting is open by default for external observers unless the Scrum Team says otherwise, but in case of retrospective it’s often better not to let external spectators in, since it may cause team members to feel threatened and restrain from sincere feedback. This means, that if there is a manager who is not part of Scrum Team, he can be kicked out if the Scrum team says so. (I’m, not talking about who has authority over who as defined in the labour code, I’m talking about rules of Scrum here).

Who should lead the Retro? The common misconception is that it should be always the Scrum Master. Actually much better idea is if each time different person takes the lead. Everyone has a different style of mastering the ceremony, and variety is the key to unleashing creativity. Of course, if the team is new and unfamiliar with Scrum, the SM should take first few Retros to give them any clue how it can be done. And provide support later anyway.

Dr When

After each sprint. On occasion, you may perform Retros covering longer period, like half a year. Perhaps a specific period like first half year after product initial release or something like that. As any Scrum meeting it should be held at stable time – perhaps Friday afternoon, last day of the sprint is best. Don’t skip it till Monday since people will forget some stuff during weekend (and this is the purpose of a weekend)

Dr Why

Simply to improve. While learning any skill if you don’t stop and think what you blew up recently, your progress will be slower. Same is true for software development, and I don’t mean just coding or technical stuff. I mean the entire process from the bird’s-eye view, coding, testing, deployment, interactions inside and outside team, soft skills usage, corporate politics etc.

Dr Where

That’s actually an interesting question. You could do the meeting in the same place every time, but the point of Retrospective is to get the most creativity, memories and insight out of people. One trick to do that, is to perform it in some different environment, even unconventional. Think about going out, sit on a grass in nearby park, or in a pub, or even in a moving tram or boat. Seems silly, but…

Dr How

The biggest doctor. There is a myriad of possibilities when it gets to organizing the Retrospective. Sure, there are teams that for five consecutive years only do the red cards and green cards each time. Probably they should get a new Scum Master. If you stick with one routine way to do the meeting, people will be bored and you won’t get much out of them. Retrospective should be interesting and fun!  There are plenty tricks, exercises or games  to get people attention, some of them might be quite unorthodox.

Dr Five Stages

You can follow the Five Stages Model, as described in “Agile Retrospectives: Making Good Teams Great”, a must read by the way. So:

Set the stage – get people’s attention, spin cogwheels of their minds and set some theme for the meeting. And make them feel safe in order to get sincere output. Example: ask them to describe the sprint in one word (and hope it’s not “disaster”) or one emoticon. Throw stuffed toys at them, tell some fun story.

Gather data – get people to create a raw output. Classic way is to have green (good things) and red (bad things) sticky notes, give people 10-15 minutes to prepare a few and put them on a table. You can add third column like “ideas”. You can further divide the table into senses – related areas “I saw”, “I heard”, “I feel”. It will boost people memory. Moving motivators is nice idea and works well.

Generate insights – get people to crunch through what they gather, analyze, discuss, think, try to find the patterns. Talk about sticky note, elaborate, group them together. Encourage everyone to speak up.

Decide what to do – get people to figure out how to improve things. Generate some to-do list, decide what’s most annoying, what should be fixed first, what can be done inside the team and what requires external actions. You can maintain a so-called Impediment Backlog to help manage that kind of stuff.

Close the Retrospective – provide some kind of summary, make people feel good about what has been done during the meeting.

An interesting idea is Retr-o-Mat. It’s a simple page that lets you generate randomly the five stage scenario for retrospective from predefined activities. For now there is over million combinations, and that number is growing.

And what are your ideas for retrospective?


Leave a comment

Posted by on September 7, 2014 in Agile


Tags: , , , ,