Mastering Delphi Programming: A Complete Reference Guide

Learn all about building fast, scalable, and high performing applications with Delphi

Primož Gabrijelčič

• Publisher: Packt Publishing
• Year: 2019
• Print ISBN: 9781838989118
• eBook ISBN: 9781838983918
• Edition: 1
• Topic: Computer Science
• Subtopic: Desktop Applications
• Index: Computer Science

Use structural, behavioral, and concurrent patterns in Delphi to skillfully develop applications

Key Features

• Delve into the core patterns and components of Delphi to enhance your application's design
• Learn how to select the right patterns to improve your program's efficiency and productivity
• Discover how parallel programming and memory management can optimize your code

Book Description

Delphi is a cross-platform Integrated Development Environment (IDE) that supports rapid application development for most operating systems, including Microsoft Windows, iOS, and now Linux with RAD Studio 10.2. If you know how to use the features of Delphi, you can easily create scalable applications in no time.

This Learning Path begins by explaining how to find performance bottlenecks and apply the correct algorithm to fix them. You'll brush up on tricks, techniques, and best practices to solve common design and architectural challenges. Then, you'll see how to leverage external libraries to write better-performing programs. You'll also learn about the eight most important patterns that'll enable you to develop and improve the interface between items and harmonize shared memories within threads. As you progress, you'll also delve into improving the performance of your code and mastering cross-platform RTL improvements.

By the end of this Learning Path, you'll be able to address common design problems and feel confident while building scalable projects.

This Learning Path includes content from the following Packt products:

• Delphi High Performance by Primož Gabrijel?i?
• Hands-On Design Patterns with Delphi by Primož Gabrijel?i?

What you will learn

• Understand parallel programming and work with the various tools included with Delphi
• Explore memory managers and their implementation
• Leverage external libraries to write better-performing programs
• Keep up to date with the latest additions and design techniques in Delphi
• Get to grips with various modern multithreading approaches
• Break a design problem down into its component parts

Who this book is for

This Learning Path is for intermediate-level Delphi programmers who want to build robust applications using Delphi features. Prior knowledge of Delphi is assumed.

About Performance

"My program is not fast enough. Users are saying that it is not performing well. What can I do?"

These are the words I hear a lot when consulting on different programming projects. Sometimes the answer is simple, sometimes hard, but almost always the critical part of the answer lies in the question. More specifically, in one word - performing.

What do we mean when we say that a program is performing well? Actually, nobody cares. What we have to know is what users mean when they say that the program is not performing well. And users, you'll probably admit, look at the world in a very different way than we programmers.

Before starting to measure and improve the performance of a program, we have to find out what users really mean by the word performance. Only then can we do something productive about it.

We will cover the following topics in this chapter:

• What is performance?
• What do we mean when we say that a program performs well?
• What can we tell about the code speed by looking at the algorithm?
• How does the knowledge of compiler internals help us write fast programs?
• Why is it better to measure than to guess?
• What tools can we use to find the slow parts of a program?

What is performance?

To better understand what we mean when we say that a program is performing well, let's take a look at a user story. In this book, we will use a fictitious person, namely Mr. Smith, Chief of Antarctica Department of Forestry. Mr. Smith is stationed in McMurdo Base, Antarctica, and he doesn't have much real work to do. He has already mapped all the forests in the vicinity of the station and half of the year it is too dark to be walking around and counting trees, anyway. That's why he spends most of his time behind a computer. And that's also why he is very grumpy when his programs are not performing well.

Some days he writes long documents analyzing the state of forests in Antarctica. When he is doing that, he wants the document editor to perform well. By that he actually means that the editor should work fast enough so that he doesn't feel any delay (or lag, as we call the delay when dealing with user input) while typing, preparing graphs, formatting tables, and so on.

In this scenario, performance simply means working fast enough and nothing else. If we speed up the operation of the document editor by a factor of two, or even by a factor of ten, that would make no noticeable improvement for our Mr. Smith. The document editor would simply stay fast enough as far as he is concerned.

The situation completely changes when he is querying a large database of all of the forests on Earth and comparing the situation across the world to the local specifics of Antarctica. He doesn't like to wait and he wants each database query to complete in as short a time as possible. In this case, performance translates to speed. We will make Mr. Smith a happier person if we find a way to speed up his database searches by a factor a ten. Or even a factor of five; or two. He will be happy with any speedup and he'd praise us up to the heavens.

After all this hard work, Mr. Smith likes to play a game. While the computer is thinking about a next move, a video call comes in. Mr. Smith knows he's in for a long chat and he starts resizing the game window so that it will share the screen with a video call application. But the game is thinking hard and is not processing user input and poor Mr. Smith is unable to resize it, which makes him unhappy.

In this example, Mr. Smith simply expects that the application's user interface will respond to his commands. He doesn't care if the application takes some time to find the next move, as long as he can do with the application what he wants to. In other words, he wants a user interface that doesn't block.

Different types of speed

It is obvious from the previous example that we don't always mean the same thing when we talk about a program's speed. There is a real speed, as in the database example, and there is a perceived speed, hinted at in the document editor and game scenario. Sometimes we don't need to improve the program speed at all. We just have to make it not stutter while working (by making the user interface responsive at all times) and users will be happy.

We will deal with two types of performance in this book:

• Programs that react quickly to user input
• Programs that perform computations quickly

As you'll see, the techniques to achieve the former and the latter are somehow different. To make a program react quickly, we can sometimes just put a long operation (as was the calculation of the next move in the fictitious game) into a background thread. The code will still run as long as in the original version but the user interface won't be blocked and everybody will be happy.

To speed up a program (which can also help with a slowly-reacting user interface), we can use different techniques, from changing the algorithm to changing the code so that it will use more than one CPU at once to using a hand-optimized version, either written by us or imported from an external library.

To do anything, we have to know which part of the code is causing a problem. If we are dealing with a big legacy program, problematic part may be hard to find. In the rest of this chapter, we will look at different ways to locate such code. We'll start by taking an educated guess and then we'll improve that by measuring the code speed, first by using home-grown tools and then with a few different open source and commercial programs.

Algorithm complexity

Before we start with the dirty (and fun) job of improving program speed, I'd like to present a bit of computer science theory, namely the Big O notation.

You don't have to worry, I will not use pages of mathematical formulas and talk about infinitesimal asymptotics. Instead, I will just present the essence of the Big O notation, the parts that are important to every programmer.

In the literature and, of course, on the web, you will see expressions such as O(n), O(n^2), O(1) and similar. This fancy-looking notation hides a really simple story. It tells us how much slower the algorithm will become if we increase the data size by a factor of n.

The n^2 notation means "n to the power of two", or n². This notation is frequently used on the internet because it can be written with the standard ASCII characters. This book uses the more readable variant O(n²).

Let's say we have an algorithm with complexity of O(n), which on average takes T seconds to process input data of size N. If we increase the size of the data by a factor of 10 (to 10*...

Table of contents

• Title Page
• Copyright and Credits
• About Packt
• Contributors
• Preface
• About Performance
• Fixing the Algorithm
• Fine-Tuning the Code
• Memory Management
• Getting Started with the Parallel World
• Working with Parallel Tools
• Exploring Parallel Practices
• Using External Libraries
• Introduction to Patterns
• Singleton, Dependency Injection, Lazy Initialization, and Object Pool
• Factory Method, Abstract Factory, Prototype, and Builder
• Composite, Flyweight, Marker Interface, and Bridge
• Adapter, Proxy, Decorator, and Facade
• Nullable Value, Template Method, Command, and State
• Iterator, Visitor, Observer, and Memento
• Locking Patterns
• Thread pool, Messaging, Future and Pipeline
• Other Books You May Enjoy