I thought I'd make a post about testing code logic in programming. Most people take programs for granted, and don't really understand what skillful programmers do to make things work well. Now, I'm not an expert in this by any means, but I have done quite a bit of my own code testing and over time have found ways to improve the code logic. I thought I'd use an example of this to show how much improvements can make, from something as simple as swapping some lines of code around.
With this in mind, I'll use a recent example of how much more efficient I made my file importer.
I was writing an image sequence importer, which my last post here was about. In writing this, I had initially written some code that would create a project clip out of an image file. In doing so, I had a piece of code which would test opening the image, to make sure the program could read the file before adding it as a clip. I also had some objects that caught some parameters about the image, such as its width and height in pixels. I had organised the code so that this was one of the first things that it did.
I then expanded the code so that it searched for any matching files, and if so, would add the image as a kind of 'join', so that the clip then became an image sequence. I managed to get all of this working fairly well.
But then I had a thought not long afterwards, that the test image open was happening for every image file. This, at least, would be a fairly secure way of making sure that the image file was valid before adding it as a clip to the project. But, it also made the process inefficient, because a large image array (for example, importing 300 image files) makes for a fairly slow import process when they are all opened during the import process.
I decided to re-organised the code so that the file was tested against other clips for matching files before I tested opening the image file itself. If the matching clip test failed (that is, there were no matching results) then I opened the file to make sure it worked and if this was successful, added the file as its own clip. In short, I swapped the order of some of the code. The difference in import times was really quite the eye opener. Here are some numbers:
Importing before the code change:
- sequence frames: 383
- image resolution: 6k
- import time: 317.984009 seconds
- 5 minutes, 17.984 seconds.
Importing after the code change
- sequence frames: 383
- image resolution: 6k
- import time: 2.07999992
- 2.079 seconds (wow!).
The process went from over 5 minutes to just a little over 2 seconds. That's a considerable reduction in processing time!
Now, it's not perfect, in the sense that there's no test open check for any of the subsequent image files before they're added to an existing clip. But I think this is worth the risk. If the initial image file opens successfully (the first one added as a clip), then I think it's reasonable to assume that any other files added to the clip (that is, added to the clip sequence) will be valid image files.
So there you go, it pays to test your own logic from time to time.