Bill Roper's Journal

We had some code that was running slowly across a list of some 20K members. It turns out that the reason it was running slowly was that rather than just adding new members, we checked each member of the list to make sure that we weren't adding a *duplicate* member with the new add. This works fine for short lists, but is pretty much abominable by the time you're adding 20K members.

"Well," I said to myself. That's easy enough to fix. I can just add a hashCode() (and matching equals()) method to the class for the members that are being added to the list; then add a HashSet to keep track of what's already in the list, because that will look things up in a hurry. In fact, we should just make a class that welds a HashSet to the side of our ArrayList, because I know I've solved a similar problem before and we may as well not have to *keep* solving it."

I then paused and ran a brief search.

Right. ListOrderedSet in Apache Commons. I figured someone else had had this problem before...

Did I mention how nice it is to be working in a language with modern libraries available?

Ah, there's nothing like going back to work on a section of the Java code that I haven't played with in a year or so. Now how does this work? :)

So, meanwhile, back at work, I think I have gotten the last bugs out of the Java side of what I was working on. Now, I just need to figure out exactly how to port all of the fixes back to C++, where the code is "similar", but not "identical". It's that difference between the two that makes porting so much fun!

Most of the objects that I'm attempting to fix up Java cloning for came together nicely.

Then, however, there are the ones that share references to a single object. This worked really nicely with MFC serialization, but it makes cloning an unholy mess.

*sigh*

I've been cleaning up one of the subsystems in our product (that I did not write) and it is now substantially faster than it was. Aside from the earlier improvements I made in it, I taught it to cache two values that my version of this particular subsystem has cached since it was written. Doing this took the execution time to retrieve and write to a text stream a grid of nearly 700,000 cells from about 35 seconds down to 19 seconds.

There's other code that's running that is still taking way too long too execute, but this particular subsystem is now running much better.

When I ported all of our C++ code over to Java, one of the things I was told was "You don't have to worry about the speed of looking things up in hash maps. They're really fast." And since maintaining shared references to a single copy of an object was a pain in the butt, I started storing keys to the objects and looking them up in a master hash map for each of the different types of objects.

Then I found out that I was spending too much time looking up some of the things in the hash maps. So I made sure that the keys for the most frequently accessed object were immutable and shared via a common cache. And then I stored the pre-computed hash code inside the key, because not having to hash the key every time would speed up the searches a lot.

But the C++ code was running too slow, as I'd replaced the old shared pointers there. So I did the same trick in C++ that I done with the shared immutable cached keys with the pre-computed hash codes. Still not fast enough though.

Well, there was this value that I had previously pre-computed and stored, but was now looking up on the fly in a hash map with potentially multiple checks per value. Let's try putting that stored value back and only updating it when it needs to be updated.

Yes, that is fast enough.

*sigh*

I have just finished porting a big chunk of code from our Java implementation back to our C++ implementation.

I swear that the thing that will kill me is the continuing drift between the two implementations. There are many lovely new methods that I have coded in Java that had to be ported back to C++ so that I could call them there. And in Java, it's an OK thing to return a List<Something>. In C++, you want to create a CArray<Something*> and pass the reference into the method that in Java is returning a List<Something>. So the method signatures get screwy as you copy code back and forth. And "." turns into "->" or vice versa.

Eventually, I also need to clean up the variant versions of the camelCasing between the two implementations so that the old C++ IsSomething() ends up being the Java-style isSomething() on both sides of the great divide. As it is, the Java code is partially converted to the new style, as is the C++ code. But not all of the same methods have been converted on both sides.

And then there is "const". I love "const" in C++. I don't have it in Java. But I have immutable classes there that I don't have in my C++ implementation.

All of this is a recipe for a great thumping headache.

Some code that had been working with piped streams in Java has suddenly stopped working. I am annoyed.

I also suspect that something is being done wrong by somebody. I just haven't figured out who or what yet.

Well, I added caching for another couple of classes today, which should reduce the memory footprint a bit further. Unfortunately, I am getting close to the point of diminishing returns.

The thing that's the real killer is a big doubly-linked list. Unfortunately, it's a big doubly-linked list that I really need.

*sigh*

So we're studying heap dumps for our Java app to try to determine why our models are taking up as much space as they are. After staring down some of the models, I dropped in a bit of new code.

The model that I was working with -- one of the smaller ones, admittedly! -- shrank by almost 10% in its memory footprint. Larger models probably won't shrink quite as much, but it was a gratifying result.

Now to see if I can use this trick in some other places. :)