Bill Roper's Journal

Sadly, I am not sure *which* one of the suspects in the code was doing the dirty deed. It is possible that the problem was the result of a little conspiracy of errors.

However, I have fixed enough different small problems that the bug has vanished. This is encouraging.

Testing. Testing is my friend.

So we've been trying to port our code up from Visual Studio 2010 to Visual Studio 2019 for a bit less than two years now. (I started aiming for Visual Studio 2017, but that eventually became an obsolete target.) Most of the code appeared to be working, but when it was finally tested by our QE team, an intractable bug popped up.

The intractable bug has been sitting there for some obscene length of time. In the last two days, we have spent four hours on a session with the other group in our company that is trying to talk to our code across COM in order to make this work. Today's session didn't manage to solve the problem either.

About ten minutes after the session ended, I went to my machine and fixed the problem by setting one switch in the compile.

My Google-fu is strong, but it really helps when you finally find out what is going wrong in the communications protocols.

*sigh*

We'll see if this fix sticks...

Having spent a fair amount of time working with Java Maps, I am being inordinately annoyed by the idiosyncrasies of boost::unordered_map.

I'll fix the code tomorrow.

Finished up the Java code for a fix I was making and fired things up so I could see how it was working. Opened up a model to give it a try.

It was *then* that I realized that the UI for this feature has not yet been ported to Java. It's still in C++ only.

Of course, I haven't ported my code to the C++ side yet. And one library that I was using that made it simple to write a particular routine I need doesn't have any C++ equivalent. I can write the necessary code to do what I need done, but it will take a little time to get it right.

So we'll see how this works next week.

*sigh*

I am working on changing the way that we handle renaming of account IDs in our product. This might seem simple, but there are a great many account IDs stored in many, many different records, all of which need to be switched over to use the new system.

And when I finish doing this in Java, I get to do it again in C++.

*sigh*

I have nearly finished a big change to the Java code base. Unfortunately, as I near the end of the process, I realize that I am going to need to make a similar change to the C++ code base.

Sadly, changing the C++ code base is a much more annoying process.

Ah, well.

Well, my new code *almost* works.

Maybe on Monday, I can get it past the "almost" stage.

I think I've gotten my current project under control on the Java side.

Now, I just need to port the code back to C++ and get it working there. :)

We've picked up a highly dimensional client file for testing here and have discovered that the calculations are running a good bit slower than they were in older versions of the product. Part of this is due to the fact that I eliminated a number of direct pointers in favor of map lookups, because I was told that maps would be very, very fast in our Java code. Well, maybe they are faster in Java than they are in C++, but they are still not fast enough in either case, because the calculations are way too slow.

So I've been putting back in various bits of caching in both the C++ and the Java code. With nothing cached, the calculations were taking a minute and 47 seconds. Caching two data items cut the time to 1:25, which was respectable, but still slower than I had in mind.

I have now cached a third bit of interesting data and have cut the calculation time down to 57 seconds.

This is good.

Tomorrow, I'll finish this up and try caching a fourth and final bit of data and we'll see where we end up. :)

It's back to the optimization grindstone for me after discovering yesterday that one of the optimizations that I put in that seemed to work really well was broken -- which was why it worked so well! I'm having a lot of difficulty improving the rendering performance by optimizing my code further. Of course, I've managed to improve that bit by fixing up not just my code, but some of the rendering code on our side of the fence to the tune of about a 37% improvement. This isn't good enough, but I'm starting to suspect that a good bit of the rendering delay is due to some change on the other side of the fence here. We'll see.

Meanwhile, today's early optimizations have improved the calculation speed by about 11%.

I can do better than that. I still know where the bodies are buried...