In Uncategorized on March 31, 2016 at 3:37 pm
StringBuilder sucks big-time. From (java 7 docs):
“Every string builder has a capacity. As long as the length of the character sequence contained in the string builder does not exceed the capacity, it is not necessary to allocate a new internal buffer. If the internal buffer overflows, it is automatically made larger.”
Admittedly this is perfectly ok for most applications. But when you’re dealing with large datasets and need to assemble string contents from god knows where and how big. What happens is StringBuilder will take up twice the memory (and processing time) because of the constant resizing and re-allocation. Development work and testing might be ok, but once its on production and the content grows larger, StringBuilder will return to bite you.
Bottomline is StringBuilder is fast for small String sizes but terrible for large data sets.
So what to do? This not being a unique problem to this writer, others have pointed out solutions. One is using a Collection for the strings, which is too tedious I think, the other is to use IO Streams. The idea is to flush the assembled strings to a file first prior and just read it back after assembly thereby eliminating the need to put it in a String buffer which can be affected by the memory issue (note all String + String code will result in a byte code that creates a StringBuilder to implement the code).
Here’s the sample code:
FileWriter fw = null;
String tempfile = System.getProperty("user.dir")+"/"+reportid+".tmp";
// write all strings to the file writer
String str = null;
catch (Exception f)
// we delete the temp file
File file = new File(tempfile);
catch (Exception f)
In Uncategorized on October 13, 2015 at 8:25 am
It’s like the Autonomy buyout by HP all over again. Bad, very bad… I suspect this is somebodys idea of an exit strategy and I dont mean just on the side of EMC execs and select stockholders (*wink* *wink*).
The writing is on the wall for EMC, on premise backups sales is declining as companies trudge towards the cloud.
In Linux, MySQL on August 23, 2012 at 1:18 pm
Recent Oracle behaviour on MySQL releases have baffled quite a number of MySQL followers. According to this:
a recent version: mysql-5.5.25, does not have the usual regression testing scripts available. These scripts have been part and parcel of MySQL since 1999 and not having these for the first time is a real surprise for active MySQL developers.
So how important are these scripts? well it turns out they are very important as it contains a compilation of old and new scripts that verify the new MySQL version a) does not have the old bugs identified with previous versions and b) contains the fixes for newer bugs.
In other words, a missing regression testing script means, the quality of this version is suspect. Probably just what the powers that be in Oracle wants to happen. As of this writing Oracle has already released 5.5.27, I wonder if that and .26 also have those scripts missing.
More than two years ago, I wrote about how Oracle only “committed” to a parallel release of the free version of MySQL up to 5 years from the closing of the purchase (of Sun and its bag of goodies) transaction. After that it’s anybody’s guess. Five years hence is January 28, 2015. Two and a half years to go, but before then I suspect we’ll see more reasons to ‘doubt’ the open future of MySQL.