Is there a memory-efficient replacement of java.lang.String?

by

With a Little Bit of Help From the JVM…

WARNING: This solution is now obsolete in newer Java SE versions. See other ad-hoc solutions further below.

If you use an HotSpot JVM, since Java 6 update 21, you can use this command-line option:

-XX:+UseCompressedStrings

The JVM Options page reads:

Use a byte[] for Strings which can be represented as pure ASCII. (Introduced
in Java 6 Update 21 Performance Release)

UPDATE: This feature was broken in a later version and was supposed to be fixed again in Java SE 6u25 as mentioned by the 6u25 b03 release notes (however we don’t see it in the 6u25 final release notes). The bug report 7016213 is not visible for security reasons. So, use with care and check first. Like any -XX option, it is deemed experimental and subject to change without much notice, so it’s probably not always best to not use that in the startup scrip of a production server.

UPDATE 2013-03 (thanks to a comment by Aleksey Maximus): See this related question and its accepted answer. The option now seems to be deceased. This is further confirmed in the bug 7129417 report.

The End Justifies the Means

Warning: (Ugly) Solutions for Specific Needs

This is a bit out of the box and lower-level, but since you asked… don’t hit the messenger!

Your Own Lighter String Representation

If ASCII is fine for you needs, then why don’t you just roll out your own implementation?

As you mentioned, you could byte[] instead of char[] internally. But that’s not all.

To do it even more lightweight, instead of wrapping your byte arrays in a class, why not simply use an helper class containing mostly static methods operating on these byte arrays that you pass around? Sure, it’s going to feel pretty C-ish, but it would work, and would save you the huge overhead that goes with String objects.

And sure, it would miss some nice functionalities… unless your re-implement them. If you really need them, then there’s not much choice. Thanks to OpenJDK and a lot of other good projects, you could very well roll out your own fugly LiteStrings class that just operate on byte[] parameters. You’ll feel like taking a shower every time you need to call a function, but you’ll have saved heaps of memory.

I’d recommend to make it resemble closely the String class’s contract and to provide meaningful adapters and builders to convert from and to String, and you might want to also have adapters to and from StringBuffer and StringBuilder, as well as some mirror implementations of other things you might need. Definitely some piece of work, but might be worth it (see a bit below the “Make it Count!” section).

On-the-Fly Compression/Decompression

You could very well compress your strings in memory and decompress them on the fly when you need them. After all, you only need to be able to read them when you access them, right?

Of course, being that violent will mean:

  • more complex (thus less maintainable) code,
  • more processing power,
  • relatively long strings are needed for the compression to be relevant (or to compact multiple strings into one by implementing your own store system, to make the compression more effective).

Do Both

For a full-headache, of course you can do all of that:

  • C-ish helper class,
  • byte arrays,
  • on-the-fly compressed store.

Be sure to make that open-source. 🙂

Make it Count!

By the way, see this great presentation on Building Memory-Efficient Java Applications by N. Mitchell and G. Sevitsky: [2008 version], [2009 version].

From this presentation, we see that an 8-char string eats 64 bytes on a 32-bit system (96 for a 64-bit system!!), and most of it is due to JVM overhead. And from this article we see that an 8-byte array would eat “only” 24 bytes: 12 bytes of header, 8 x 1 byte + 4 bytes of alignment).

Sounds like this could be worth it if you really manipulate a lot of that stuff (and possibly speed up things a bit, as you’d spend less time allocating memory, but don’t quote me on that and benchmark it; plus it would depend greatly on your implementation).

More Related Contents:

  1. Why does appending “” to a String save memory?
  2. Fastest way to strip all non-printable characters from a Java String
  3. Java split String performances
  4. StringBuilder vs String concatenation in toString() in Java
  5. When to use StringBuilder in Java [duplicate]
  6. Java Reflection Performance
  7. Swing animation running extremely slow
  8. Java get available memory
  9. boolean[] vs. BitSet: Which is more efficient?
  10. Fastest way to iterate over all the chars in a String
  11. Should I use Java’s String.format() if performance is important?
  12. Size of a byte in memory – Java
  13. Efficiently compute Intersection of two Sets in Java?
  14. Java local vs instance variable access speed
  15. Java HashMap performance optimization / alternative
  16. Does variable = null set it for garbage collection
  17. Which loop has better performance? Why?
  18. Performance penalty of String.intern()
  19. How much memory does a string use in Java 8?
  20. Garbage collection behaviour for String.intern()
  21. Is the ternary operator faster than an “if” condition in Java [duplicate]
  22. Java: A two dimensional array is stored in column-major or row-major order?
  23. Most efficient way of converting String to Integer in java
  24. What’s wrong with using associativity by compilers?
  25. How many string objects will be created in memory? [duplicate]
  26. Why defining class as final improves JVM performance?
  27. How to remove large if-else-if chain [duplicate]
  28. Hashmap vs Array performance
  29. Split string to equal length substrings in Java
  30. Fatal Error: Invalid Layout of java.lang.String at value

Leave a Comment