What Simple Changes Made the Biggest Improvements to Your Delphi Programs

Question

I have a Delphi 2009 program that handles a lot of data and needs to be as fast as possible and not use too much memory.

What small simple changes have you made to your Delphi code that had the biggest impact on the performance of you program by noticeably reducing execution time or memory use?

---

Thanks everyone for all your answers. Many great tips.

For completeness, I'll post a few important articles on Delphi optimization that I found.

Before you start optimizing Delphi code at About.com

Speed and Size: Top 10 Tricks also at About.com

Code Optimization Fundamentals and Delphi Optimization Guidelines at High Performance Delphi, relating to Delphi 7 but still very pertinent.

Answer 1

Separating the program logic from user interface, refactoring, then optimizing the most-used, most resource-intensive elements independently.

Answer 2

• Turn debugging OFF

• Turn optimizations ON

• Remove all references to units that you don't actually use

• Look for memory leaks

Answer 3

Pre-allocating lists and arrays, rather than growing them with each iteration.

This has probably had the biggest impact for me in terms of speed.

Answer 4

When working with a tstringlist (or similar), set "sorted := false" until needed (if at all). Seems like a no-brainer...

Answer 5

Make intelligent use of SetLength() for strings and arrays. Optimise initialisation with FillChar or ZeroMemory.

Local variables created on stack (e.g. record types) are faster than heap allocated (objects and New()) variables.

Reuse objects rather than Destroy then create. But make sure management code for this is faster than memory manager!

Answer 6

Check heavily-used loops for calculations that could be (at least partially) pre-calculated or handled with a lookup table. Trig functions are a classic for this, but it applies to many others.

Answer 7

If you need to use Application.processmesssages (or similar) in a loop, try calling it only every Nth iteration.

Similarly, if updating a progressbar, don't update it every iteration. Instead, increment it by x units every x iterations, or scale the updates according to time or as a percentage of overall task length.

Answer 8

.BeginUpdate;

.EndUpdate;

;)

Answer 9

Use a lot of assertions to debug, then turn them off in shipping code.

Answer 10

Turn off range and overflow checking after you have tested extensively.

Answer 11

If you really, really, really need to be light weight then you can shed the VCL. Take a look at the KOL & MCK. Granted if you do that then you are trading features for reduced footprint.

Answer 12

Use the full FastMM and study the documentation and source and see if you can tweak it to your specifications.

Answer 13

Take advantage of some of the FastCode project code. Parts of it were incorporated into VCL/RTL proper (like FastMM was), but there is more out there you can use!

Note, they have a new site they are moving too, but it seems to be a bit inactive.

Answer 14

Maybe take advantage of the VCL FixPack by Andreas Hausladen

The VCL Fix Pack is a Delphi unit that fixes VCL and RTL bugs at runtime by patching the original functions. If you want all IDE Fix Pack fixes in your application this unit is what you need. Adding the unit to your project (Delphi and C++Builder) automatically installs the patches that are avilable for your Delphi/C++Builder version.

Answer 15

Use a Delphi Profiling tool (Some here or here) and discover your own bottle necks. Optimizing the wrong bottlenecks is a waste of time. In other words, if you apply all of these suggestions here, but ignore the fact someone put a sleep(1000) (or similar) in some very important code is a waste of your time. Fix your actual bottlenecks first.

Answer 16

You might consider using runtime packages. This could reduce your memory foot print if there are more then one program running that is written using the same packages.

Answer 17

Consider hardware issues. If you really need performance then consider the type of hard drive(s) your program and your databases are running on. There are a lot of variables especially if you are running a database. RAID is not always the best answer either.

Answer 18

1. Create unit tests
2. Verify tests all pass
3. Profile your application
4. Refactor looking for bottlenecks and memory
5. Repeat from Step 2 (comparing to previous pass)

Answer 19

Consider the careful use of threads. If you are not using threads now, then consider adding a couple. If you are, make sure you are not using too many. If you are running on a Dual or Quad core computer (which most are any more) then proper thread tuning is very important.

You could look at OmniThread Library by Gabr, but there are a number of thread libraries in development for Delphi. You could easily implement your own parallel for using anonymous types.

Answer 20

For an old BDE development when I first started Delphi, I was using lots of TQuery components. Someone told me to use TTable master-detail after I explained him what I was doing, and that made the program run much faster.

Calling DisableControls can omit unnecessary UI updates.

Answer 21

1. FastMM
2. FastCode (lib)
3. Use high performance data structures, like hash table (etc). Many places it is faster to make one loop which makes lookup hash table for your data. Uses quite lot of memory but it surely is fast. (this maybe is most important one, but 2 first are dead simple and need very little of effort to do)

Answer 22

Before you do anything, identify slow parts. Do not touch working code which performs fast enough.

Answer 23

Reduce disk operations. If there's enough memory, load the file entirely to RAM and do all operations in memory.

Answer 24

Stop using TStringList for everything.

TStringList is not a general purpose datastructure for effective storage and handling of everything from simple to complex types. Look for alternatives. I use Delphi Container and Algorithm Library (DeCAL, formerly known as SDL). Julians EZDSL should also be a good alternative.

Answer 25

If you use threads, set their processor affinity. If you don't use threads yet, consider using them, or look into asynchronous I/O (completion ports) if your application does lots of I/O.

Answer 26

Consider if a DBMS database is really the perfect choice. If you are only reading data and never changing it, then a flat fixed record file could work faster, especially if the path to the data can be easily mapped (ie, one index). A trivial binary search on a fixed record file is still extremely fast.

Answer 27

When identifying records, use integers if at all possible for record comparison. While a primary key of "company name" might seem logical, the time spent generating and storing a hash of this will greatly improve overall search times.

Answer 28

• BeginUpdate ... EndUpdate
• ShortString vs. String
• Use arrays instead of TStrings and TList

But the sad answer is that tuning and optimization will give you maybe 10% improvement (and it's dangerous); re-design can give you 90%. Once you really understand the goal, you often can restate the problem (and therefore the solution) in much better terms.

Cheers

Answer 29

Examine all loops, and look for ways to short circuit. If your looking for something specific and find it in a loop, then use the BREAK command to immediately bail...no sense looping thru the rest. If you know that you don't have a match, then use a CONTINUE as quickly as possible.

Answer 30

if you have to do a string comparison, use the optimized STRCOMP or TEXTCOMP functions. For simple equality, use the optimized SAMESTR and SAMETEXT functions. Always choose the SAMESTR/STRCOMP if you know the case will always be the same.

Answer 31

The biggest improvement came when I started using AsyncCalls to convert single-threaded applications that used to freeze up the UI, into (sort of) multi-threaded apps.

Although AsyncCalls can do a lot more, I've found it useful for this very simple purpose. Let's say you have a subroutine blocked like this: Diable Button, Do Work, Enable Button. You move the 'Do Work' part to a local function (call it AsyncDoWork), and add four lines of code:

var  a: IAsyncCall;    
a := LocalAsyncCall(@AsyncDoWork);  
while (NOT a.Finished) do 
  application.ProcessMessages;  
a.Sync;

What this does for you is run AsyncDoWork in a separate thread, while your main thread remains available to respond to the UI (like dragging the window or clicking Abort.) When AsyncDoWork is finished the code continues. Because I moved it to a local function, all local vars are available, an the code does not need to be changed.

This is a very limited type of 'multi-threading'. Specifically, it's dual threading. You must ensure that your Async function and the UI do not both access the same VCL components or data structures. (I disable all controls except the stop button.)

I don't use this to write new programs. It's just a really quick & easy way to make old programs more responsive.

Answer 32

If you have a list, use a dynamic array of anything, even a record as follows: This needs no classes, no freeing and access to it is very fast. Even if it needs to grow you can do this - see below. Only use TList or TStringList if you need lots of size changing flexibility.

type
  TMyRec = record
    SomeString : string;
    SomeValue : double;
  end;

var
  Data : array of TMyRec;
  I : integer;

..begin
  SetLength( Data, 100 ); // defines the length and CLEARS ALL DATA
  Data[32].SomeString := 'Hello';
  ShowMessage( Data[32] );

  // Grow the list by 1 item.
  I := Length( Data );
  SetLength( Data, I+1 );

..end;

Brian.

Answer 33

Avoid using a TTable with lookup fields when a TQuery will do.

I had a report that was extremely slow in a large database. It used a TTable with a bunch of lookup fields. I hung a network monitor on my application and found that an enormous amount of data was flowing across the lines as I traversed this TTable with lookup fields. Changing to a TQuery dramatically reduced the amount of traffic and made a huge difference in speed.

This advice is really just learning to think in client-server terms.

Answer 34

Run SysInternals ProcessExplorer and FileMonitor, and watch the behavior of your app from teh OS point of view. You'll find surprises such as unexpected disk and registry activity. Where you may have thought that you were saving your settings to the registry or .ini file all in one operation, you may be performing 100 writes. You may find that a database write takes 30 writes when you thought you were doing 3. Some of this can be tuned with things like transactions and buffering. But not until you find the trouble spots first. I had such an "awakening" when I put my app through U3 certification (SanDisk U3 drives have their own certification). I never did make much money by having a U3 version of my app, but the excercise was well worth it.

Answer 35

Avoid thread.synchronize if possible. This stops everything and waits for the VCL thread. We changed most of our synchronizes to use thread.queue where they could be done asynchronously. The use of anonymous methods helps here as well.