The helpful CPU window
In situations similar to the previous example, it doesn't hurt if you can look at the generated assembler code to check what is going on behind the scenes. Luckily, Delphi IDE provides a great way to do just that.
I will be the first to admit that examining assembler code is not for everyone. You can be a great Delphi programmer and still have no idea how to read assembler instructions.
If you found yourself in the previous words, don't worry. This section is included just for people who want to know everything. You can safely skip it knowing that you'll still be able to understand everything else in the book. However, if you're still interested then, by all means, read on!
The Delphi IDE gives us a few different tools for viewing the low-level state of the code and computer. They are stowed away in the not-so-obvious submenu View, Debug Windows, CPU Windows. The most useful view is called Entire CPU and encompasses all other views in that submenu. It is displayed as an editor tab named CPU.
Be aware, though, that it is only useful while you are debugging the program. The best way to use it is to pause the program (either by inserting a breakpoint or clicking the pause icon or selecting the Run, Program Pause menu) and then switch to the CPU view.
This view is composed of five parts. The Disassembly panel (top left) shows your code as assembler instructions intermixed with Pascal source lines for easier orientation. If you don't see Pascal lines, right-click into that view and verify if the menu item, Mixed source is checked.
On the right of that (top right corner) are two small panels showing processor registers and flags. Below them (bottom right corner) is the current thread's stack. To finish it up, a panel in the bottom left corner shows the process' memory at some address.
If you use the F8 key to step to the next command while the Entire CPU view is active, Delphi will not step to the next Pascal instruction but to the next assembler instruction. If you want to go to the next Pascal instruction, use the Shift + F7 combination or menu Run, Trace to Next Source Line.
We can use the CPU view to verify that the first code example from the previous section really compiles to much worse code than the second example.
The image here shows part of the code from the original (on the left) and hand-optimized method (on the right). Green rectangles mark the code that accesses ListBox1.Items[i]. We can clearly see that the original code does that three times before calling the Pos function (at the very bottom of the image) while the hand-optimized method executes the same sequence of instructions only once:
