When I started my job at work I was given the task of speeding up our software.

At first I thought it was a mammoth task but that was mainly because I hadn't ever used the programming language before. Then I realised that there were quite a few areas that could be optimised and speeded up a bit.

Now, 7 months later, I am beginning to realise that the task is bigger than I thought it was.

It's quite fun though.

The main problem we have is the speed of the network between the depots and the server at our head office.

I keep whittling away at trying to speed up searches and reduce the number of times the App server get's called etc..

Anyway, random post but Big_D inspired me to write it after his post about lazy programmers in the Meeting Place.

I think it's fantastic that a company actually pays someone to make their software work faster. I always thought they considered it a "good" thing when a software upgrade called for twice the memory, double the processing power and ten times the network performance - after all, if it needs a super-computer it must be super-software!

I have lots of thoughts on the subject, but nothing of value to add. If you find a brilliant way to make a WAN seem ten times faster, I'd love to hear it

Just a random thought...Could you, hypothetically, add a very small, cheap server at the depot, and have that cache popular requests from the server at the head office? I imagine it being something of a half slave/replica of the master at the HO...

I suppose we could but the outlay would be massive. We have 200+ depots.

Also the speed at which the data changes is actually quite fast. The sevrer at HO caches all the recent table indexes it has had to produce so that when people are calling the same requests over and over all it has to do is send the data back, it doesn't go trawling through the database to get it.

The bugs I have come across are ridiculous though.

Say you want to open the order for a particular customer but you don't know the customer account no. You press the binoculars to search for the customer and type in the name.

It then goes off to the server to get the accounts that comply with the search string. You double click the one you want but then, instead of passing back the customer record, it passes back the customer rowid.

The calling program then takes the rowid, passes it to the app server and gets the customer record?!?!

It's got the same data from the server twice when it blatantly didnt' have to!

The one thing I would say is that, if the call which returns the Id is generic, then it isn't a surprise that it only returns the Id.

If you are creating a new order for the customer, all you require is the customer Id, you don't want to waste time/bandwidth retrieving all of the customer information. That said, I would expect an option in the class to be able to automatically load the customer's data.

Well, I've been working on it on and off and today I finally found the last piece of the puzzle that was stopping it from working!!!

Now I have to transfer it from my little area (for protecting the dev version) on to the ACTUAL dev version.

Should take me about a week to work out what I've done and re do it.

Can't wait! I'm expecting at least a 50% increase in performance across the board!

Fingers crossed!

Never publicly state the amount of improvement you anticipate from a change! (8-p)

We've got some fairly major performance issues, but they're also showing highlighting problems in our test harnesses (8-()

Hehe

I was publicly confident (with my manager etc...) that I would get a 30% increase.

Quietly I thought it would be more like a 50% increase.

I put the system on and it's all working now (apart from a few niggles that have come over from the old method of working) and I ran some tests.

The actual result showed an increase in performance of over 100%

My boss was very pleased and so was I!

Not bad for a couple of weeks work and I've only been here (and using the language) since December

On an old HP150 (8088 prozessor @ 6Mhz ISTR), I got over a 3000% performance improvement on one app! 8) It was display every account number it processed, it had to process hundreds of accounts, so I changed it to display ever 50 or so.

yes years back we told excel not to refresh screen until it finished a calculation. went from 2 days to 20 minutes to run the macro.

Woot!

Well my optimisation has managed to work it's way back to the underlying architecture of the business model.

I asked for free run of the server connection whilst working on a particular program that I have been asked to either speed up or rewrite and I was given it.

With that I went all out "Mr. Best Practise" on it and restructured the code on the front end and on the server.

Consequently the action of typing in an order number and pressing TAB (this sends off to the server to check the order number is correct, confirming the type/number of the order and getting the customer name and account number etc...) has given the following numbers...

1. On the current live system - 43 TCP packets transferred across the network with a total size of 7.7KB taking 0.65 seconds (across GBit LAN).

2. With my newly implemented system - 3 TCP packets transferred across the network with a total size of 1.1KB taking 0.205 seconds (across the same LAN).

Considering that I haven't cut out any of the information (excess fields in tables etc...) that gets to the front end I'm fairly pleased with the result.

Like for like tests show around a 60% drop in network data transfer a 90% drop in the number of packets (bigger packets but a lot fewer and fewer packets with pointless acknowledge - confirm - acknowledge, etc... with no actual data being passed) and about a 70% drop in the time between the request from the GUI and the data coming back.

Woot!

As a direct result of the work I have done we are now organising a complete restructure of the architecture of our system!

Double woot!

I initially misunderstood this but now I realise what you mean.

Essentially the gui was getting the customer record from the database, then going back to the database to get the rowid, then passing the rowid to another screen on the gui which then went back to the database to get the customer record using the rowid.

I basically changed it so that the gui gets the customer record but then instead of passing back the rowid of the record just pass back the record itself.

This then allowed direct access to the information without having to go back to the database again.

Yep, that sounds about right. It is amazing how far some people take the de-coupling.