Delphi 2010 - lessons learned converting from Delphi 2007

*Upgrading from Delphi 2007 to Delphi 2010*
(as of February 1, 2010)
        I bought a new computer in December and decided to upgrade from Delphi 2007 to Delphi 2010.  Here are some lessons learned related to the Delphi upgrade, which I hope will make a similar transition easier for others.  I still have an insurmountable problem with the speed of the IDE (#13 below).
        As background, my old system had 3 GB of RAM, 40GB of unused disk, a 3.8 GHz CPU, and ran under Windows XP.  My new system has 12 GB of RAM, 770GB of unused disk, a quad core 2.67 GHz CPU, and runs under Win7 Home Edition.          
        I encountered many major problems in converting my main application (320,000 source lines) from Delphi 2007 to Delphi 2010.  Smaller projects and utility programs converted without any trouble.  Please note that I am not a Delphi ‘guru’ (though I have been programming for 40+ years and in Delphi for 5 years) and there are apt to be inaccuracies in some of the statements below, since most of them are based on my personal experience and not a definitive knowledge of how the Delphi 2010 internals work.
                                
1.      The very first thing to do is to create a definitive list all the libraries your source code uses: where the package (dpk), source modules, (pas), compiled modules (dcu), design time library (bpl), and run time compiled library (dcp) files are stored.  You need all this information to provide search paths and folder names so Delphi can find the libraries when it needs them.  Oh, and you should do that for your application code too, of course.  You did get the latest versions of all those libraries so t
hey support Delphi 2010, didn’t you?
2 .     The 3 chapters by Mario Cantu on converting from ASCII to Unicode should be read and Mario’s advice followed so that the conversion from single byte strings to double byte strings doesn’t cause problems.  The compiler will identify most of these for you and between what Mario has written and the compiler you shouldn’t have too much trouble making this change.  It may take some time to perform all the edits, depending on your existing code.  I found I needed to also examine older (third party) free lib
raries I was using in some detail to make sure they executed Unicode correctly.  Actually, by eliminating unused routines, I cut 90% of the modules from these libraries, reducing the number from 443 to 43.  By so doing, I had far less code to worry about for the conversion to Unicode.
                                                                
3.      The ‘automatic’ conversion of old project files (dproj) to new is not necessarily performed well by Delphi 2010.  Because I was changing both computers and operating systems, the old settings were sometimes complete nonsense, especially for search paths.  You need to go through all the general settings for your projects in Tools - Options - Environment Options.  Especially important is Delphi Options - Library - Win32 if that is what you are using (see below).  
4.      I strongly recommend making a copy (in a simple text file) of all the settings you discover when you first open: (1) Tools - Options and (2) Project - Options.  Then you should keep a record of what you try and any success/failure you experience.  Yes, this is tedious to do.  But believe me, when lost in the labyrinth of the project settings, it is a great comfort and time saver to be able to return to your starting point (or last most successful parameter settings) and review what you have already tri
ed.  And, no, you will not be able to retain all that information in your head.  I have an excellent memory, able to play chess blindfolded, and this stuff was way beyond my ability to keep track of it.
5.      Tools - Options - Environment Options - Delphi Options - Library - Win32 had a lot of values defined by the automatic conversion that I had to edit (through trial and error).  The Library path is for source code and appears to be used by the compiler (obviously) and also the debugger (for identifying individual lines in the source code for reporting in the call stack).  You should have an entry for Package output directory and DCP output directory.  For Browsing path, Namespace prefixes, and Debug DCU 
path, I have blank entries.  One of the Delphi forum members reported that the presence of extraneous entries in the Directories settings caused the IDE to run slowly.  I am under the impression that cleaning these up did increase the IDE’s speed of execution for me - though I have no definite proof of that.  Regardless, neatness counts in programming.
6.      Tools - Options - Environment Options - Tool Palette - Environment Variables also had garbage carried over from the Delphi 2007 settings.  Note that these apply to all projects and they can be modified for individual projects in Projects - Options - Debugger - Environment Block.  I found this quite confusing since Tools - Options contains User overrides, and then Project - Options also contain User overrides.  My sense of this is that it is a layering of defaults and overrides.  Figuring out what is go
ing on internally exceeded my patience.  I just made sure the setting for the project was the best I could get it.  In practice, I eliminated all the overrides except for Path.  Note that this is one place where my point #4 comes in very handy.  The User overrides are a concatenated string of path names and infuriating to work with as such.  For example, some of my paths are strings of 500+ characters, each of which have to be absolutely correct.  Adding and removing path names, even simply reading the cu
rrent path names, is a real pain.
7.      Project - Options - Delphi Compiler contains 3 build configurations: Base, Debug, and Release.  The IDE always assumes you want to use Base which is very annoying.  I have to believe that programmers spend 99% of their time using Debug, which means that the first thing you should do when you fire up the IDE is go into this drop down menu and set the Build Configuration to Debug.  I got the Base settings the way I wanted them and then let the IDE insert its default changes for Debug and Release.  The Se
arch path is the most difficult setting to get correct here.  This is where you need to know where your library code is stored.  Now the Search path inherits from the Environment options, so a lot of this was taken care of when you set #6 above.
        However, I removed:
        •       $(BDS)\Lib,
        •       $(BDS)\Lib\Indy10, and
        •       $(BDSCOMMONDIR)\Dcp
                
        from my Environment path and added them to the Search path for the Project.  My logic was to keep the Environment path as clean as possible (this may be a misguided notion).  What is important here is to have the folders that contain the Dcps in this list.  Intensely aggravating is that if you are missing a folder for a Dcp, the compiler reports that the Bpl cannot be found.  That is completely wrong; it is the Dcp that it can’t find.  Many an hour can be irrecoverably lost trying to figure out why the c
ompiler can’t find a Bpl.  May the programmer that wrote that code have a fiery post life experience.
8.      Project - Options - Resource Compiler - Directories and Conditionals inherits its settings from #7.  I added $(BDS)\Dcp to this path.  Oh, by the way, I delete invalid paths whenever I encountered them.  The only exception is when it is clearly a typo on my part.
9.      Project - Options - Debugger - Source path contains only one addition for my project (for a third party library), but this doesn’t appear to do anything since the debugger still can’t find that library’s source code (for inclusion in the call stack).
10.     Okay, here is the biggest change I had to make to my code.  None of this was true for Delphi 2007!  The ‘uses’ clauses in each of your modules should be pristine, completely devoid of references to modules that are not needed.  The compile time for my complete project (i.e., after deleting all the DCUs) ran to over 5 minutes.  Once I had cleaned up all the uses clauses (360 modules, 2 uses clauses per module) the compile time for the entire project was 16 seconds.  
        Now these edits were extraordinarily time consuming to do and mercifully a friend told me about the freeware program  Icarus from Peganza.com.  That lovely little program analyzes all your files when you give it the name of your project file.  Icarus’ very long report identifies unused references for each module and also identifies references that should be in the Implementation section instead of the Interface section.  Now it isn’t perfect, with some false positives (i.e., it says the reference isn’t n
eeded when it really is).  But it found 99.9% of the unused references correctly for me and I figure it saved me 40-50 hours of work.  Even with this automated help, it took me a long time to make all the edits in the 360 modules.
        The payoff is clearly visible in the time require to compile the full project, or even just a couple of modules that you have changed.  I have to believe it also improves the response time of the IDE when debugging, though I still have major problems with that.
11.     I still get a fatal error whenever I try to do a Build.  This crashes the IDE and requires me to use the Task Manager to terminate Delphi 2010.  Though I find this bug to be astonishing, it isn’t an impediment to me getting work done.  I just do a Compile of the project and Delphi creates the EXE without complaints by it or me.
12.     Somewhat annoying is the 15 seconds the IDE takes the first time I click on Search from the main menu bar (or equivalently use the shortcut Control-Shift-F).  After the first global search the response time is under a second, but the first one always takes ~15 seconds.  I assume it is doing some preparatory work and searches through all the files in my project.  This doesn’t happen with small projects.  Before I made the #10 changes above, this use to take 5 minutes.  There is no way to Esc from this 
command if you enter it by accident.  You either wait for it to complete or use the Task manager to kill Delphi 2010.  I have encountered this at other times too for other IDE commands.  I am not sure what provokes this bizarre behavior by the IDE but whichever programmer/analyst/manager made this decision about the IDE interface deserves a job building igloos in Death Valley in the midday sun - when he completes 100 of them he can take a 5 minute break.
13.     Completely unacceptable is the response time of the debugger.  As you can tell by the above, I have made massive attempts to get this to function correctly.  As it is, the debugger can disappear (i.e., busy cursor) for minutes at a time when executing my application.  When the same program is run stand alone (outside of the debugger in XP emulation mode), the response time is instantaneous, as it was when I used the Delphi 2007 debugger.  But if I execute the program from within the IDE, the program c
an come to an abrupt halt at virtually any time - usually very shortly after I start its execution.  If I am lucky, the debugger returns from its introspection in 2-3 minutes.  I have seen it take 10+ minutes and I now use the rule of thumb that if it takes 2+ minutes I kill Delphi 2010 using the task manager.
14.     I have implemented the small fix to the IDE by Andreas (http://andy.jgknet.de/).
                                                                        
        I’ve spent the last 6 weeks working on this every day.  Any ideas or help would be appreciated.
        Steven Hokanson (SHokanson@HawaiianTel.net).
0
Steven
2/1/2010 10:45:26 PM
📁 embarcadero.delphi.ide
📃 3925 articles.
⭐ 0 followers.

💬 5 Replies
👁️‍🗨️ 1526 Views


Hello,
Steven Hokanson wrote:
> 13.        Completely unacceptable is the response time of the debugger.  As
> you can tell by the above, I have made massive attempts to get this
> to function correctly.  As it is, the debugger can disappear (i.e.,
> busy cursor) for minutes at a time when executing my application.
> When the same program is run stand alone (outside of the debugger in
> XP emulation mode), the response time is instantaneous, as it was
> when I used the Delphi 2007 debugger.  But if I execute the program
> from within the IDE, the program c an come to an abrupt halt at
> virtually any time - usually very shortly after I start its
> execution.  If I am lucky, the debugger returns from its
> introspection in 2-3 minutes.  I have seen it take 10+ minutes and I
> now use the rule of thumb that if it takes 2+ minutes I kill Delphi
> 2010 using the task manager.
if you have a reproducible case for this, you could find out what the
debugger is doing by starting the IDE from within its own debugger, and
when it freezes again, hit F12 to find out what it's doing (-> call
stack etc.).
-- 
Moritz
"Hey, it compiles! Ship it!"
0
Moritz
2/1/2010 11:30:40 PM
>> 13. Completely unacceptable is the response time of the debugger.
Moritz Beutel wrote
> If you have a reproducible case for this, you could find out
> what the debugger is doing by starting the IDE from within
> its own debugger, and when it freezes again, hit F12 to find
> out what it's doing (-> call stack etc.).
Steven and Moritz,
I note this suggestion in QualityCentral
  Report No: 45646            Status: Closed
  Add performance monitoring into IDE
  http://qc.embarcadero.com/wc/qcmain.aspx?d=45646
  QCWIN:Defect_No=45646
I note that it is closed.  It was supposed to give you a way 
to monitor what the IDE was doing and record the configuration 
of your machine in a text form, so that we could more easily 
compare notes in these forums.   Perhaps this QC suggestion 
never got implemented.  <sad> --JohnH
0
John
2/2/2010 12:07:44 AM
Hello,
to be really useful, that feature would probably need to have
method-level coverage info - and then you could just as well run the
IDE in a profiler. For example you could try Eric Grange's Sampling
Profiler (http://delphitools.info/) - I believe it uses the package
exports to map position data to method names.
-- 
Moritz
"Hey, it compiles! Ship it!"
0
Moritz
2/2/2010 12:16:01 AM
> {quote:title=Moritz Beutel wrote:}{quote}
> Hello,
> 
> Steven Hokanson wrote:
> 
> > 13.   Completely unacceptable is the response time of the debugger.  As
> > you can tell by the above, I have made massive attempts to get this
> > to function correctly.  As it is, the debugger can disappear (i.e.,
> > busy cursor) for minutes at a time when executing my application.
> > When the same program is run stand alone (outside of the debugger in
> > XP emulation mode), the response time is instantaneous, as it was
> > when I used the Delphi 2007 debugger.  But if I execute the program
> > from within the IDE, the program c an come to an abrupt halt at
> > virtually any time - usually very shortly after I start its
> > execution.  If I am lucky, the debugger returns from its
> > introspection in 2-3 minutes.  I have seen it take 10+ minutes and I
> > now use the rule of thumb that if it takes 2+ minutes I kill Delphi
> > 2010 using the task manager.
> 
> if you have a reproducible case for this, you could find out what the
> debugger is doing by starting the IDE from within its own debugger, and
> when it freezes again, hit F12 to find out what it's doing (-> call
> stack etc.).
> 
> -- 
> Moritz
> 
> "Hey, it compiles! Ship it!"
===========
This is eminently reproducible.  
Maybe I am being a little dense here, but how do I "start the IDE from within its own debugger"?
0
Steven
2/2/2010 12:18:03 AM
Hello,
Steven Hokanson wrote:
> Maybe I am being a little dense here, but how do I "start the IDE
> from within its own debugger"?
using "Run|Load process...", for example. Or you could launch two IDE
processes and attach one to the other.
-- 
Moritz
"Hey, it compiles! Ship it!"
0
Moritz
2/2/2010 12:22:55 AM
Reply: