Please read the DISCLAIMER before you use any of the tips from this web site. Go to main index

Tip 70:  Optimizing recursive routines

(modified: 22 Jan 2004)

Tip 32:  Exe compressors

(modified: 10 Jul 2000)

Tip 35:  Using a profiler

(modified: 13 Aug 2000)

Tip 30:  My Delphi 3 to Delphi 4 experience

(modified: 02 Jan 2001)

Date added/modified: 22 Jan 2004

Notes to myself on optimizing recursive routines:

• Inspect all the variables used in the routine and its subroutines. Try to reduce the stack requirement.
• If you are using objects, do not use properties unless they directly point to a class variable.
• Redesign such that the unnecessary processing is avoided in the routine and is rather passed as a parameter. For example, if in the beginning of a routine, you find the level of the current node. This is waste since the level can be calculated and passed as a parameter, especially since it is a recursive routine. Finding the level needs to be done, may be, only on the first entry but not on subsequent ones.

Date added/modified: 10 Jul 2000

I discovered an interesting write up on EXE compressors on the following page:

http://www.jordanr.dhs.org/striprlc.htm#execomp

I am convinced, and I have decided to use the compressed EXE format only for my evaluation versions to avoid hacking and piracy. I have removed the compression from my licensed versions. This works as an additional incentive for the registered users.

Date added/modified: 13 Aug 2000

If you don't know what a profiler means, a "profiler" allows you to measure how much time it takes to execute different parts of your program. The idea is to improve the performance by finding the problem areas.

Recently, I had a requirement to use a profiler. Actually, I wanted to speed up certain processing for my product ShowSize. Earlier, during C++ days, I had made my own profiling tools for C++.

When I went to look for a Delphi profiler on Torry's site, I found many of them. But, most of them seemed too much automated. They claimed to insert code in your source automatically. What I wanted was more control on which code segment I wanted to profile and one that allowed me to measure average time in big loops that executed thousands of times.

Well, I found one exactly that met my needs. It is called Delphi Profiler. The web site:

Before I give you the web site link, let me point out that Delphi Profiler is difficult to find on that site. It is under the section "Frogbit." http://www.axiomati.demon.co.uk/

Using this tool, I was able to find the problem area in some new feature code in ShowSize and speed it up by using alternate alogorithms to fill a view. How dramatic was the improvement? On a user's system, the view population by some sort algorithm used to take more than 10 minutes. When I finished up adding my own sorting instead of using the control's built-in sorting, the whole process took only 7 seconds!

So, yes. If you want to make heavy duty tools, you must use profilers.

Date added/modified: 02 Jan 2001

Latest note: Since moving to Delphi 5, I have found that the same problem exists in Delphi 5. But, I have worked around it as indicated.

Most of my applications are non-database utilities and are still in Delphi 3. Although, I bought Delphi 4 long back, I was reluctant to immediately port all my applications to Delphi 4. This intuition comes from a long association with programming products. Who knows what new problems might be created with a newer product? Well, my intuition seems to be right. Here is the story.

Instead of rereleasing my applications with Delphi 4, I ported only a pilot product to Delphi 4. Everything seemed to work fine and I was about to decide to switch all my remaining applications to Delphi 4. Suddenly, I found that this new product was too slow in filling up the background report view. I remembered using the Delphi 3 version which was fast enough. No code had changed. I again ran Delphi 3 executable and it worked fast. Naturally, I suspected something wrong in Delphi 4 VCL.

Well, after some investigation I found that in TListView, I was using a width of -1 and -2 for two of the columns. This made Delphi 4 VCL to fill up the list view very slowly, in spite of using beginupdate/endupdate. The same settings for widthType in Delphi 3 worked OK. When I changed the width to a positive value, the problem was fixed!

There are other differences too. While Delphi 3 TListView always stores width as positive value, irrespective of what you store in widthType, in Delphi 4, the width is always same as widthType.

On the other hand, the new TListView in Delphi 4 has virtual mode. So eventually, if I need to use it, I will have to go to Delphi 4. Now, that Delphi 5 is released it might be better to drop Delphi 4 entirely and directly go to Delphi 5. But, all that can wait till I need the new features. As a developer of non-database utilities, I am quite happy with Delphi 3

Copyright 1995-2004, Sanjay Kanade. All rights reserved.
All trademarks and copyrights belong to their respective owners.