dow.ngra.de

After getting a lot of comment SPAM on different sites I thought I’ll run a quick experiment. Launch a honeypot, almost disable spam prevention and check out the statistics. More details on the honeypot page.

I was waiting for the Gmail themes tab to appear on the settings page but it never did. I run Gmail under Prism and I hardly ever log out. Once I did do that and logged back in I finally got the themes tabs. Running terminal right now, nooooot.

For many years I was convinced that Maven was a plot to bring the community of Java developers to the point of extinction. It is very slow in development, overengineered and imposes a set of standards where a 20 line build script would suffice.

On the other hand I was always envious of the way Maven manages dependences and downloading 20 megs of dependencies every time I do a fresh checkout was a bit of a embarrassment. Well, last week it all changed.

What happened is that Kristian Rosenvold contributed a JavaRebel plugin. Him being a fan of Maven and me being a fan of JavaRebel we wanted to find some way to set up a Maven repo for various JavaRebel projects that wouldn’t expose me to the things I consider unholy. Lo and behold, the Maven guys have figured out our pains and provided the nifty library called the Maven Ant tasks.

Now this maybe ancient news to the Maven community, but being a hardcore Ant hacker I have always thought that Ivy is the best and latest in the Maven-Ant integration game. Ivy does the job, but it is a pain to configure and even after three years still very buggy. The Maven Ant tasks can use the standard Maven pom.xml files if you like them, or to configure everything in Ant if you don’t.

The basic gist is that you put the following three lines in your build script:

This gives you a path dependency.classpath that includes all your dependencies and that you can refer as pathref or classpathRef. It is also possible to get a fileset of dependencies as well as individual dependencies using properties of the form ${groupId:artifactId:type}.

With the dependencies in such a form it’s trivial to use them even in existing build scripts. You just replace your current paths and sets with the Maven ones an voila — you get a hackable Ant script with all the pleasure of Maven and without any of the pains.

A few days ago I had a small epiphany on a simple yet important issue. I was trying to squeeze those last few percents of performance out of JavaRebel and it came to the point where I started optimizing individual hotspots method-by-method.

One of the most common ways to improve execution time of a specific method is the cutoff. For many complicated enough methods there are some inputs for which you can return immediately and cut off the main execution path. To explain let me use the following example:

This method could do anything as long as the complexity is constant, we only care how much time it takes on average. I could also have taken some algorithm (e.g. I started with matrix multiplication), but then we’d have to bring in complexity estimates and I’d like to keep it simple for now.

Let’s assume that for some inputs we could calculate the output in 50ms instead of 200ms. We introduce a check and the code is now:

This is a common way to optimize the method execution time. However the question is if this actually optimized anything? It seems like a stupid question, but let’s estimate the new average execution time.

To do that we need to know two things. The time t it takes to do the isSimpleInput() check and the proportion p of method calls that are “simple”. Let’s assume that t is 20 ms and 10% of the calls are simple. The average execution time can then be calculated using the expected value formula (EV = p * v1 + (1 – p) * v2):
EV = 0.1 * (20 + 50) + (1 – 0.1) * (20 + 200)
= 20 + 0.1 * 50 + 0.9 * 200
= 20 + 5 + 180 = 205

This calculation shows that with this values we have actually increased the average method execution time by 5 ms. Note that we are still winning every time the cutoff occurs (20 + 50 << 200), but we are losing on the average.

The same equation can also be applied to measuring several checks or measuring execution time that is dependent on the input, however it gets increasingly more complicated. For me the main value of this is realizing that every cutoff has an inherent cost which I will now pay in mind.

Before you think this is all just math, the epiphany that came to me was not to add a check, it was to remove one. I realized that a particular check I’m making is rare and expensive enough to directly influence the method execution time and lo and behold, removing it gave a 30% improvement for the benchmark I was using.

The previous post on dow.ngra.de generated tons of traffic. That tons of traffic generated 120 000 requests to a style sheet file that did not exist. Wordpress will display a semi fancy page for 404 files that weighs about 25 KB. 25 KB times 120 000 is 3 000 000 KB :).

Actually the same happened to favicon.ico and a few others. So either have your referred files and favicon.ico on your server or rework Wordpress mod_rewrite configuration not to handle css/js/ico/png/gif/jpg files. This will save you money!