Posts Tagged ‘Java’

GNU Trove 2.x to 3.x migration

April 12, 2013 Leave a comment

Based on this this post, here is a script to help migration from GNU Trove version 2.x to 3.x.

#! /usr/bin/python
import sys
import re
import tempfile
import os
import shutil

 "TObjectHashingStrategy": "strategy.HashingStrategy",
 "PrimeFinder": "impl.PrimeFinder"}
def do_a_file(filename):
    output, output_name = tempfile.mkstemp()
    output = os.fdopen(output, "w")
    rawstr = r"""import gnu\.trove\.(.*);"""
    compile_obj = re.compile(rawstr)
    for l in in_file:
        match_obj =
        if match_obj != None and len(match_obj.groups()) > 0:
            if clazz[:1].islower():
            elif trove2_to_trove3.has_key(clazz):
            elif clazz.endswith("ArrayList"):
            elif clazz.endswith("HashMap"):
            elif clazz.endswith("HashSet"):
            elif clazz.endswith("Iterator"):
            elif clazz.endswith("Procedure"):
            output.write("import gnu.trove."+new_class+";\n")
    shutil.move(output_name, filename)

for root, subFolders, files in os.walk(sys.argv[1]):
    for file in files:
        if file.endswith(".java"):
Tags: , ,

Language Benchmark: Java Vs Python (The return)

May 28, 2010 1 comment

In my previous post I compared I/O and string formating and python was better than Java. Anyway as Java have primitive types and do not need to box/unbox variables it could be realy faster than python. Here is an exemple where I compute the distances between 3D points.

The python code

import time
from numpy import *
from math import *

n = 1000000
v1 = zeros(n*3)
v2 = zeros(n*3)
dn = double(n)
for i in xrange(n):
    v1[i] = 1.0 + i / dn;
    v2[i] = 2.0 + i / dn;
r = zeros(n)
t1 = time.time()
for i in xrange(n/3):
    for j in xrange(3):
        r[i]=r[i] + (v1[i*3+j]-v2[i*3+j])**2
t2 = time.time()
print t2-t1

The Java code

	public static void main(String[] argv)

		int n = 1000000;
		double[] v1 = new double[n*3];
		double[] v2 = new double[n*3];
		for(int i = 0; i < n; i++)
			v1[i] = 1.0+i/(double)n;
			v2[i] = 2.0+i/(double)n;

		double[] r = new double[n];
		double tmp;
		long t1 = System.nanoTime();
		for(int i = 0; i < n/3; i++)
			for(int j = 0; j < 3; j++)
				tmp = v1[i*3+j]-v2[i*3+j];
				tmp = tmp*tmp;
				r[i] += tmp;
			r[i] = Math.sqrt(r[i]);
		long t2 = System.nanoTime();
		System.out.println("time: "+(t2-t1)/1E9);
		for(int i = 0; i<n; i++)


  • Java: 0.02s (with a precision of 0.05s)
  • Python: 9.49s


There are probably ways to improve my python code using numpy a better way, but most of the time to get rid of boxing/unboxing time you will have to write C code to speedup most critical part of algorithms. While Python is only a gluing (yet very good) technology, Java can be used to write fast low level algorithms.

Tags: ,

Java: what about giving back the memory to the OS ?

February 23, 2010 Leave a comment

Here is a common scenario when using Java for desktop applications:

  1. start a Java application
  2. run an algorithm which require a lot’s of memory
  3. release the memory once the algorithm is terminated
  4. start an other application (Java or not)
  5. swap the unused java memory of the first application

Between step 3 and 4 everyone would expect Java to give some MB back to the OS, but it does not. Thoses MB would be very useful to run the second application. By default Java will not give memory back to OS unless at least 70% of the Java memory is free. Moreover it will always allocate 40% more memory than needed. Theses ratio are controlled by two JVM options:

  • -XX:MaxHeapFreeRatio
  • -XX:MinHeapFreeRatio

I’ve been running Netbeans on large projects and large files (made by dirty developers, as Java files should never be large) with following options:

  • -XX:MaxHeapFreeRatio=10
  • -XX:MinHeapFreeRatio=10

and did not notice any performance issue. I no longer need to close Netbeans before running an other memory consuming application. I just close all tabs I do not need anymore, and can see the effect on system memory with the top command.

I thinks that 10% (or less ?) could be the default for long time running desktop applications. May be it’s also true for servers.


Netbeans DataObject life cycle

December 11, 2008 Leave a comment

Here are some questions which I did not found any answer on the Netbeans wiki:

  • When are DataObject created
  • When are DataObject destroyed
  • Am I expected to store custom data in DataObject

Answers can be found in the openide.loaders/src/org/openide/loaders/ file, in the source code:

  • DataObject are, at least, created when Netbeans need to display a Node representing a FileObject, that is, each time an explorer browse a file system.
  • DataObject are stored as WeakReference in the DataObjectPool instance. They are freed when memory is required.
  • As you do not control when DataObject are created nor disposed you should probably not load nor store data when the DataObject is created. It should be done by actions associated to the DataObject.

There is a funny side efect of using WeakReference to keep track on DataObject. If you open a directory with a lot’s of large DataObject, some of them may be destroyed by the garbage collector as soon are the are created. Then corresponding nodes are not displayed.

Tags: ,

Speed up collapse and expand in JTree

January 18, 2008 Leave a comment

JTree is slow… Google this and you will find it is a well known problem. For one of my application I need to do collapse and expand operations on all nodes of a large JTree. Even with the large model flag set it’s take 20 seconds to expand the whole tree. Profiling the execution with Netbeans profiler we can see that 100% of the time is took be the UI. It seems to propagate changes to the UI after the expand/collapse of each nodes. So a way to speed up this is to remove the UI during the operation:

TreeUI ui = myJTree.getUI();

EDIT 2015-10-17, A comment from Johny that I received by e-mail:

First I wanna thank you for the idea, but also point out that it’s wrong. Yes, the reason that expanding all nodes of a JTree is slow is because the JTree GUI will paint() the updates once for every row it expands. So for thousands of expanded rows it is super slow.

But you cannot do this “solution”. If you setUI(null), you will remove the TreeUI’s critical listeners from the JTree, which means the UI is not aware of rows being expanded or collapsed anymore. So your UI “backup” is out-of-date. Then when you setUI(theOldUi), it will look ok, until you try to add some more rows, then it will cause null pointer exceptions because the GUI internal cached data is out of sync with what happened in the tree while the GUI was disabled.

What you MUST do:

myTree.setUI(new BasicTreeUI()); // or whatever GUI you used before.

but instead of setUI you can just use myTree.updateUI() to instantly set it to the normal default for the current look & feel, which is always what you want unless you’ve made your own custom UI!

Also remember that the setUI() will reset any custom things like custom row indentations, setShowGrid, etc, so you will have to re-apply those too.


Java: Why is the Capture of a Wildcard Incompatible with Itself?

November 18, 2007 Leave a comment

I just link this article of Peter Ahé (member of j2se team), because I don’t understand:
Sometime generics are mysterious.


Language benchmark: Java vs Python

November 18, 2007 1 comment

Here is a nice web site to compare languages properties: But I did not found the test I was looking for: writing/reading float text stream. So I wrote mine.
Read more…

Tags: ,