Why Is My Consignment Software Slow?

It’s likely not your computer, nor your network.  Even on the fastest hardware, using Solid State Drives (SSDs), specific screens or even the entirety of your consignment software can respond slowly and show ‘Not Responding‘.

Why?  It’s the programmer’s fault — blame your software vendor.  When you write software, if you don’t take one additional step, then your software will not be multi-threaded.  The result is, if the software has to wait for something, the program will appear to lock-up and you won’t be able to click or type, until the program has finished the task.  Sound familiar?

Let’s show an example of this.

I wrote a little test application, which counts to 10.  Watch what happens if I don’t do anything to make it multi-threaded:

Notice how you can’t see it count up to 10?  You have to wait 10 seconds until you see the results.  Notice how I could click Button #1 and Button #2 before I told it to count to 10, but once I told it to start counting, Button #1 and Button #2 no longer worked?

Now let’s take a look at how a multi-threaded application handles the same event:

Notice how you can actually see it count up to 10 now?  I can also click my other buttons while it’s counting.  i.e. the program responds and doesn’t make me wait until it’s finished doing stuff.  😉

How does one make an application multi-threaded?  First, let’s look at the code as it is, without making it multi-threaded:

Now let’s look at the same code, once it’s been made to be multi-threaded:

If this looks like gibberish to you, no worries.  🙂  Let’s take a closer look.

In our non-multi-threaded example, when we click our ‘Go’ button, it just starts what it’s been told to do, without any consideration as to what happens while it’s counting:

In our multi-threaded example, notice when we click our button, it doesn’t just “go do stuff.”  Instead, it has a simple command that tells it, “Hey, go get this little piece of code and run it in its own thread.”:

The result, is an application that responds while it’s busy.  One line of code is all it took.

So why wouldn’t a programmer utilize this to prevent their software from locking-up while it’s busy?  I can only imagine, but as you can see in the examples above, it’s not because it takes a long time to do, nor is it complicated, nor does it cost anything.  It’s simply an approach to application design and some take the rough, “just go do this” approach, while others are sensitive to how their users’ experience will be.  They don’t want their users to have a bad experience, which leads them call in and complain about the software locking-up.  If a user has to call to report an issue, it takes time out of everyone’s day.

Now, there are some factors that can lead to slow performance — e.g. a really old processor, or a really slow network — but that’s the whole point.  i.e. The programmer has to should take into consideration, what happens when her/his software encounters environments that can have a negative impact on the software.

In summary, applications that lock-up, are something most any programmer wants to avoid.  It only takes a line of code to change this, so why not utilize this feature as much as possible?  Good question.  😉

I hope this sheds some light on why consignment software stops responding, while it’s busy.