Recently I took a CUDA course and one of the things they mentioned to keep an out for was the usage of double precision. Double precision operations are slower and the added precision wasn’t worth it, so they say. This made me wonder whether this is also true for regular programming with languages such as C++ and Java. Especially because both of these languages have a double precision as the default floating point number. So how bad is it to use doubles instead of regular float, and what about that precision. I have investigated this in Java.
A Map is a very common data structure to use, and often you find yourself wanting to traverse over all elements in it. For this we have multiple methods:
If you are interested in both the keys and the values, the valueSet does not fit your needs as it is impossible to get the key based on the value. But which one of the remaining two ways performs the best? I did the test and found some interesting results.
When it comes to writing high performance software there are different approaches we can take. These different paths, match with how important performance is considered to be.
The first does not consider performance as anything important, the program is written without any attention towards how it performs. Only after users start complaining about the performance, actions are taken to fix it. Users will only complain if it is a killer for them, it isn’t tolerable and thus should be considered a bug.
Another way could be to write software the same as before, but checking the performance from time to time. When the performance of the software falls below some level, action must be taken. This prevents users from complaining, as the performance is boosted before it becomes critical.
A final way is that performance is taken into account when writing software, and is part of the design. This means constant monitoring of the performance, evaluating the choices that are made and making sure it stays above the required level. This level of performance that is desired is often higher than in the previous case.
But what are the consequences of each of these approaches? Is there a single best way to tackle performance?
With the rise of cloud computing and the on-demand available capacity, I sometimes hear people say that software automatically scales, all you have to do it place it in a cloud environment such as Amazon. The reason why people tend to believe this, comes from all the propaganda made by such companies. They tell you tales of how your system adapts the the load automatically, and use cases of companies which had a drastic increase in load overnight, and how well it worked with the cloud environment.
While it is true that in a cloud environment it is pretty easy to start multiple ‘instances’ that run the software, this does by no means has anything to do with true scalability. Just considered we have a common desktop application, or even something that normally is installed on a server on-premises. We now decide to abandon the costly infrastructure required to run this software, and move it to a cloud environment as is.
A test should be designed such that it can be executed as fast as possible, getting the result as soon as possible, preventing interrupting the process of developing. A popular test framework to test web UI’s is Selenium. However, these tests can take much longer than they should be, which is something I experienced lately. To solve this I have investigated the cause of these slow tests, and how they can be improved.
A major reason for slow tests, are failing tests. While this may not be too common, as a failing test should be a warning and a trigger to fix what was broken, it does happen. A failing test often is waiting for something to become visible, present, selected or another state. Due to some changes in UI or bad selectors, we may be looking at the wrong element, or an event was sent wrongly.
The wait often involves a numerous amount of seconds to give the UI some time to refresh and update.
A first step to decrease the build time of a Selenium testsuite is to make sure all tests pass. This should be evident, and is not further discussed here. A second step to decrease the build time of any testsuite is to make sure your tests don’t do obsolete work. This can be any type of actions, such as restoring a backup but never using it.
While these two actions hold for any type of test, there is a third action that only holds for Selenium. The expression used to select an element, since selenium offers various ways to select an element, it is hard to know what the best approach is. Which is why I have compared them.
As a software developer I like to come up with algorithms and structures that enable me to write software that pushes things to its limits. During my studies at the University of Antwerp, I learned a lot about the complexity about algorithms, and I am really thrilled to come up with more advanced techniques each day.
With the increased capacity of hardware, the skill of writing software as optimal as possible, both time and memory wise, is being less appreciated. In that aspect I may have been born too late, as nowadays a lot of software is written without any consideration of the size and consumption of it, as the hardware can handle it anyway.
But when I think of it, better hardware should not allow us to write less optimal software, it should allow us to write software that does more.
The product we develop uses a lot of XML documents, some of those are stored in eXistdb. For those who never heard of eXistdb, don’t panic, neither did I before I started working here. And even then it took me some time to figure out what it was, and why they choose to use it.
The idea behind eXistdb is to have one data model to represent the data across all layers of your application, which would be XML. With a traditional database you would have to convert the XML data when storing and retrieving it, introducing some overhead.
In the past week I have been investigating some performance issues we had when searching for documents stored in eXistdb. In this blog post I will tell you about my findings, and how I solved them.