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 Mac OSX, Uncategorized on June 27, 2012 at 10:00 am
Who would have thought that MacOSX has a limited set of readily (ie out of the box) supported printers? I certainly didn’t. Three days after getting an MBP and the same issue with my previous Fedora 15 laptop crops up.. these creatures have a pitiful set of drivers, in this case only two (!!) generic ones for HP printers:
Pitiful MacOSX Lion Printer Setup
I cant even find my HP Laser 1020. Anyway, you can get the drivers from Apples driver site (took some scrounging to get the link):
In Uncategorized on January 17, 2012 at 9:09 am
The Samsung Smart TV has been tantalizing me and my (new) wife for months now.. the only thing that’s stopping us from buying it is we can’t bring ourselves to buy something which we may not really use regularly (we’re info junkies and tend to use our respective fondleslabs everywhere), as I’ve unplugged from the cable company more than a year ago my old small Aiwa CRT is really all we need to watch the occasional local news.. for now anyway.
At the 2012 CES, Samsung announced that it’s expanding its ‘smart’ strategy by allowing developers to access their new generation appliances. This opens up the possibility where appliances can be used by food suppliers or distributors to provide subsidized or even free appliances. Following the business model of telcos where they subsidize mobile devices for a 24-month lock-in period, it would not be far-fetched to think that a supermarket will offer a free fridge in exchange for a period where stock of certain consumable items (e.g. eggs, milk, juice, washing machine detergent etc) are automatically replenished (assuming the fridge detects low inventory and sends orders).
It will probably be a logistical nightmare but the possibility of free appliances in exchange for products we already consume anyway may just be a new model for many industries.
In Uncategorized on June 26, 2010 at 11:27 am
found this really funny video about Java..
In Uncategorized on April 29, 2010 at 10:14 am
The AWS US-West move (from US-East) is almost done.. we’ve moved 5 server instances but the main mail server is proving to be a real drag and moving 250GB of customer emails translates to 2Tb (uncompressed) of data that needs to go through the wire.. unfortunately, at this point, AWS does not provide an easy way to copy volumes or snapshots from one region to another so we have to write our own email transfer app… no, rsync wont cut it. This is the second time we’ve transferred emails from one data center to the other and the strategy that worked for us is first to write an email transfer app that not only compresses but can also crawl a unix user’s mail dir.. at any rate, its there and the transfer sequence we employed is:
- Copy Oldest Emails First. This is the bulk of the transfer, so we have to copy the emails from say 15 days past to the earliest (e.g. if we are to do this today — April 29 — then all emails before 2010-04-14 23:59:59). Copying all these emails will take days…
- Copy Recent Emails starting from (1) — ie 2010-04-15 00:00:00 – up to yesterday. This is a smaller set and now we’re almost at sync with the new server. This typically takes less time (in our case only for a few hours). Once that’s done..
- Direct all SMTP/IMAP/POP3 connections to the new Mail Server – at this point the users may miss yesterday’s emails. But this step is necessary so no new emails goes in the old mail server.
- Copy yesterdays emails to the new mail server — once done all emails would have been recorded and users see their previous day’s emails.
There’s going to be a couple of calls about ‘reappearing emails’ but customer support should be able to handle it.
One effect of the transfer from AWS East to AWS West is of course improvement in latency.. from an average of 300++msec to 230msec.. its a 25% improvement. Of course this is relative to where most of our customers are (in Asia). AWS West (having been in operations for less than a year) also has newer machines so we’re also seeing improvements in application performance. Overall, we’re satisfied.