image provider

StringBuilder Optimiser


This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have prepared to help you is right here.

This project outline is not like the artificial, tidy little problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project and research the information yourself to solve them.

Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.

Though I am a programmer by profession, I don’t do people’s homework for them. That just robs them of an education.

You have my full permission to implement this project in any way you please and to keep all the profits from your endeavour.

Please do not email me about this project without reading the disclaimer above.

I’m curious just how clever HotSpot is about optimising StringBuilder. If it is not clever about the following optimisations, write a byte code optimiser that implements them. In other words, your optomiser would analyse the compiled class files rather than the Java source, or modify the HotSpot JVM (Java Virtual Machine). It might just list its recommendations, rather than modifying any source or byte code. Failing that write one that optimises source code. Here are some possible optimisation, most difficult first:

  1. When allocating the StringBuilder, compute the length where possible to create the exact size. StringBuilder requires you to give an estimate in the constructor of how long the resultant String will be. If you guess too short, StringBuilder will have to take time out in the middle of building the String to allocate a new internal buffer double the size and copy the contents over. If you guess too long, you waste RAM (Random Access Memory). Sometimes I anally write code to precisely precompute. Usually I just make a wild guess. Neither is satisfactory. What I would like is something that would have a look at my source code and make good estimates, and insert debugging code to check if the estimates were correct. Any bad ones can be manually corrected and flagged not to be meddled with on future optimisation runs. In the simplest case, the optimiser would look for code of the form sb. append( stringliteral ) or sb. append( stringconstant ). It would total up the lengths. It could ignore the variable length pieces, allowing you to handle them manually, perhaps just indicating how many there were.
  2. When doing toString, if the char[] internally is the already the correct length, steal that array to use in the generated String and lazily make a copy (which should be rarely needed). This would require a native class and knowledge of JVM internals to cheat.
  3. Convert sb.append ( a + b + c ) to sb. append( a ); sb. append( b ); sb. append( c );
  4. Convert sb.append ( xxx ); sb.append ( yyy ); to sb. append( xxxyyy );
  5. Convert sb.append (   ) to sb.append ( ' ' );
StringBuffer project

This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Canadian Mind Products
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number