A project I have been working on for several years apparently has gotten so large that the tooltip evaluation of symbols and expressions when in design mode is very sluggish. Despite having a quad core with 4GB of RAM (only 3 GB is relevant since it's Windows XP), when I hover the mouse over code items the tooltip look-ups can frequently take 3 to 7 seconds. Every now and then I hit some part of the code that causes a big hit on the hard drive and those can take up to 15 seconds to complete. I can only assume that the data structures that Delphi uses for symbol tables and other code items involved in tooltip driven look-ups has gotten unwieldy.
I don't want to turn off tooltip evaluation because it is invaluable to my work. Is there a technique or IDE plug-in that could help speed up the tooltip evaluation in the Delphi 6 IDE?
The first thing to try is Andreas Hausladen's DelphiSpeedUp. Frankly, if that doesn't do anything for you there's not much else left to try.
Oh, and for what it's worth, your Delphi IDE will only be able to see 2GB of address space since it is a 32 bit process which does not mark itself as LARGEADDRESSAWARE.
A code clean up of unused units could help. It can be done with the free / open source tools cnWizards (Uses Cleaner wizard) and Icarus. (Icarus also shows which units can be moved from interface to implementation).
It also helps to reduce project build and link time (in one project, it dropped from 30+ seconds to 5).
This happens to me too. A guy I work with has implemented his own custom code-completion system, which I am not at liberty to share, but which is pretty cool. The closest commercial thing that I have seen to what you're asking for is Castalia, although it focuses on speeding up code-completion, rather than code-insight and tooltips, I believe it does both.
Note that my experience is on much newer versions of Delphi. In my opinion, Delphi 6 and Delphi 7 code completion can't be much improved upon except by abandoning Delphi 6 and Delphi 7.
You might find that adding all your units to your project .dpr file and reducing and eliminating as many folders from your search path, and your library path as possible helps. Also, you might want to make your component folders all use a common DCU output folder, and keep only that one DCU-based folder in your library path. That always speeds up Delphi 6/Delphi 7 for me.
I am using a TScaledLayout as a background and after I load the project a few times ALL visual components become invisible, they are there and will compile and run fine but I cannot get them to become visible again. Has happened 4 times now and have had to revert to a backup each time.
I have encountered quite a few bugs in the IDE when using Firemonkey - it is nowhere near as reliable as VCL (yet). In particular the '.lfm' and '.pas' can become unsynchronised, so that there are components in the lfm, which are defined not in the pas file.
This doesn't seem to affect runtime but sure can be confusing when you are coding... Try checking to see that all of the components in the lfm are also defined on the form. There also seems to a few issues surrounding form inheritance, where you just have to do a lot of things manually as changes to ancestors are often not picked up by descendants.
Also note that most Firemonkey components also now have a property called 'DesignVisible'. Check to see that this is set correctly.
I am running Delphi 2010 on both a 64 bit windows machine (Win 7), and a 32 bit windows machine (XP).
I am trying to learn how to use the TRibbon control.
I have been following the example in Marco Cantu's 2009 Handbook and watching YouTube Demos, but my control is not working like that as explained in the book or demos.
I added two tabs, by right clicking the control. However, the TRibbon looked as exactly as it does in my screenshot, when i drop it on the main form. It is not as high as the ones in the books or youtube demos.
I have tried the same thing on my Win 32 laptop running Windows Xp and Delphi 2010 and get the exact same results
here is what it looks like on my machine
here is what it is suppose to look like in a demo
Once again. When it drop it on the form, it does not take the shape and height as that as i see in the demos. Even when i add tabs. Did i do something wrong during my Delphi 2010 installation?
I managed finally to reproduce the problem in Delphi XE (Update 1) on Win7 64 with Aero enabled. It seems that the size gets set wrong in the .DFM file, and because the Ribbon doesn't support manual resizing you can't visually fix it in the IDE (although it appears correctly at runtime) or in the Object Inspector. It occasionally appears correctly at runtime, but it seems that's sporadic as well.
It's a nasty bug, because it makes it impossible to design the Ribbon. You can add RibbonGroup items, and assign the ActionManager, and try and design it completely using the Structure Pane, but of course that's not a practical solution.
Fortunately, there's a pretty easy workaround, although it's annoying to have to do. :)
I managed twice to get the following workaround to function, but starting over it failed to work several times, so it's a possible way around it (no promises - worked in XE, consistently failed in XE2 Update 2):
Right-click on the Ribbon and add at least one tab.
Right click on the form in the IDE, and choose View as Text from the context (pop-up) menu.
Find the Ribbon control in the .dfm text, and change the Height from the 26 that the IDE assigned to 200. (The next step will adjust it, but that's fine - the 200 fixes the immediate problem.)
Right-click again, and choose View as Form, and the Ribbon should display correctly.
(I reported it in QC against XE2 Update 2, as the problem also exists there - QC #101642)
I traced it to TCustomRibbon.GetCaptionHeight, specifically
FCaptionHeight := Max(GetSystemMetrics(SM_CYCAPTION), 26);
It seems like the GetSystemMetrics call is returning something less than 26 on certain Win7 configurations (although I can't figure out why yet). There are a couple of commented lines in that method that seem to alter the result, but as I said they've been commented out.
The strange part is that in the TCustomRibbon.Create, the Height is set by a call to GetRibbonMetric(rmFullHeight), which sets the Result := cRibbonHeight + GetCaptionHeight;, and cRibbonHeight is a constant defined as cRibbonHeight = 117;.
Finally think I've tracked this down. In the declaration of TRibbon, there's a published property declaration:
published
...
property Height default TCustomRibbon.cRibbonHeight;
Because this is the default, it appears that any other value means that the call to GetRibbonMetric mentioned above doesn't happen (see the TCustomRibbon.Create mentioned above), and the strange result from the call to GetSystemMetric causes the erroneous value 26 to be saved as the 'other value`. Wierd; will update the QC in the AM.
Addendum: Updated QC report with additional details.
Addendum: QC report opened in May 2012, but does not appear to have been resolved as of XE5 Update 1 (checked Jan 2014).
I release a single executable (.EXE) for a desktop program using Delphi 2009. I have no external DLLs or resources that I need for the program to run.
I use two components: LMD Innovative's ELPack and Sergey Tkachenko's TRichView that are compiled into my executable.
When I build my production version, using the "Release" build configuration, the executable file produced is 13,533 KB.
Prior to using Delphi 2009, I was using Delphi 4. The executable it produced was only 2,671 KB while incorporating the same two components and basically having the same code as my current version.
I do understand that Delphi 2009 is completely Unicode (which is the main reason why I upgraded), and being Unicode can cause up to a doubling of size. But this is about 5 times larger.
Is there a reason why my executable has to remain 5 times larger? Or are there some simple ways to cut down a significant chunk of the executable size?
Please note. Some people are answering with ways to compress the Delphi EXE. That is not what I am trying to do. I am trying to simply see why so much space is being used to remove what might not be necessary. If that is done, compression can still be done afterwards if so desired.
It really doesn't matter how big or small the executable is once it is installed. It is for downloading purposes and to minimize server load and download times that you want to compress it. I prefer to use Inno Setup and compress the program inside the install routine itself. Then when it is installed, it is expanded to full size. That both prevents possible detection as a virus and eliminates the extra startup time needed to uncompress the program in memory. Also I code sign both my executable and my install routine and some compression techniques are incompatible with that.
For more info about compressing, see the StackOverflow question: Delphi EXE compressor?
ldsandon asked me to provide exactly what options I'm using, so here they are:
(source: beholdgenealogy.com)
(source: beholdgenealogy.com)
When moving from Delphi 7 to Delphi 2010., our .exe's grew for example from 16 megs to 35 megs.
I asked a question similar to yours on the Embarcadero forum a few weeks ago. (link) In my OP, I listed a series of links on this subject that you might find helpful.
We tried using UPX to compress our .exe's. Letting it work for hours significantly reduced our .exe, but we probably won't use it in production for these reasons:
We have quite a few .exe's and don't want to wait 1/2-day on each build. (It's possible that we could find a non-brute force set of parameters to UPX that would reduce this...)
Although the size of the .exe is reduced, our shippable was not, because our installer (not surprisingly) is unable squeeze much more compression out of the already compressed file... whereas it was able to reduce the original 16 meg .exe down to 8 megs.
I've read some reports that at some time (rarely, but not never), UPX exe's triggered various anti-virus programs to report the application contained a virus. (I don't recall the date, site, or details of where I saw this, so it's a bit unfair of me to report it here.) But, we are so adverse to taking a risk of that even possibility happening, that UPX is off the table...
The link on the Embarcadero forum also includes a link to another SO thread on this topic.
I continue to be surprised and disappointed at the code bloat we found when moving to Delphi 2010. As Nick notes, 2X for Unicode is quite excessive.
However, the bloat is a relatively minor trade-off when moving to D2010, because, IMO, D2010 is such a terrific upgrade in so many other ways. But, it does mean that we'll probably have to move to shipping 2 CDs rather than one. I'm not looking forward to seeing the reaction to this from our organization...
Without seeing the actual settings that your "Release" build configuration uses explaining this increase in size requires a great deal of speculation.
Beyond some perhaps unlikely factors resulting in a vast increase in the amount of code being "dragged in" even though it isn't used, that magnitude of increase would most easily be explained by the inclusion of debug information.
I would check your compiler and linker settings for:
Debug Information (compiler setting)
TD32 info (linker)
Remote debug info (linker)
Compare these settings in your Delphi 2009 project with the equivalents in Delphi 4.
Factor out the expected 2X increase from Unicode and you end up with a 2.5X increase unaccounted for. This makes sense considering how many versions you've skipped. A lot's been added to the VCL and RTL since Delphi 4, and not all of it is stuff that can be easily smartlinked out, even if you never use it. Depending on how many units you're using, you could be hauling in quite a bit of extra baggage.
Allen Bauer and the compiler team added a new feature into D2010 to help reduce this, but apparently they're treading cautiously and didn't use it in as many places as they could have. Hopefully we'll see more cruft reduction in 2011 and subsequent releases.
I will add my few words.
Linker can remove unused procedures and functions only if it can follow the code hierarchy. The nightmare list for linker listed below:
Message-driven code, the sad news is that this code can't be removed whatsoever, that's why Delphi blank project size continues growing from version to version. Every new windows message (WM_TOUCH for example as long as I know introduced recently) creates procedure call hierarchy that can't be removed (even if you don't have plan to use Touch API at all). This is because every case WM_: fragment is something linker can't decide whether it will be used or not.
Code and data structures accessed from the begin end, initialization, finalization secions of the units. Here you have some control, remove unnecessary calls or object creation. Even if you create objects on demand and only free them in finalization section, make it carefully
Use "upx - compress or expand executable files" # http://upx.sourceforge.net
If you go to tools/configure tools, and set it up like this, you can compress the executable that you're working on easily via a menu item in the IDE.
Another way is to have a look to 'what unit increase the size ?'.
To do this, I use the JCL 'Project Analyser IDE', integrated in the IDE with the JCL/JVCL installation, it show you all the units with their respective size. You can export it in text file.
If you do it with the 2 environnements (D4 & D2009) you will have a lot of pertinent informations.
I've done some tests to see the difference between D2007 and D2010, because we are upgrading to D2010. I've tested a medium sized management GUI application, with about 60 forms (grids with detail forms, frames, etc). We're using TMS components + Remobjects.
D2007:
"normal" compilation: 18.8mb
with debug dcu's: 18.8mb (same size!)
D2010
normal: 23.9
debug dcu's: 48.8mb (!)
So using debug dcu's doubles our exe size...
Test with our business service (no big dfm's):
D2007: 12.3mb
D2010: 17.1mb
So yes, D2010 increases the exe (a bit), but this is not a problem for my customer.
Edit: some information about compiled size:
D2007:
D2010:
So an increase of code size, but a more than doubling of the data!
If you don't want to use an exe compressor then you should give StripReloc a try.
Check format of your dfm-s. They must be in binary format if you want to make your exe smaller.
1) You are generating a detailed map file, and because you've set "used debug dcus" it will also contains symbols for the RTL/VCL units. If it is used by an exception handling systems to generate call stacks and the like, it could be added to the executable. And if not compressed somehow, it could make your .exe size pretty large.
2) Using debug dcus will also make your .exe somewhat larger because usually they are compiled without optimization and debug options set, and they will make also your code slower. They shouldn't be used in a release version.
3) Debug information should add debig info only to the unit and not to the executable, although it is required IIRC to generate the map file.
Since D2010 adds extended RTTI, and RTTI is a notorious factor in increasing exe size, it would be interesting to see how big D2009 binaries are for that application.
If D2009 binaries are significantly smaller, it is not Unicode etc. For my own binaries, I only have a 30% increase or so going from D7 to D2009.
It has been stated earlier that using an executable compresser reduces the size of the exe but not of the install package. However, if you want a good compressor then try ASPack.
#Tom1952: ASPack is pretty fast, just a few seconds to compress a file
Also you can change the Icon. Icon in newest delphi IDE (ie XE3) is Vista/7 compatible and contains all sizes (up to 256x256 as far as I know). So you can reduce exe file size with changing the Icon.
The standard units in you newer delphi may contain more strings and constants such as error strings, that is included even if you disable debug information. Check your uses.
Don't have much of a somution besides not using a specific unit, or removing unneeded data from it.
(My experiences are with Delphi 5)
For Delphi 10.3 Rio with default setiings:
Step 1: Switch from Debug to Release in "Projects" window. This reduced my exe file from 22 MB to 5 MB !
Step 2: Use an exe compresor like ASPack. It further reduced my exe file to 1.3 MB. Unbelievable, isn't it ? :)
Uncheck debug information in project options.
If embarcadero can't provide any solution or explanation!!! I think the solution is simple: don't stuck only with Delphi there is a lot of programming languages, every one is limited only by programmer imagination.
We used Delphi 6 long times ago. Our problem, that Delphi have two problems with DFMs:
1.)
When some linked resource (like DataSet) will removed, Delphi many times forget to ask you that "some of the resources are linked, you need to redirect...". This happens, when the actual form is not added to the project, or it is not opened.
2.)
When we only open the DFM, and only see some thing, may we change it (active TabSheet, form position).
Then Delphi auto save the form - and sometimes it drops the links.
Another problem with this that we used SVN, and SVN detect these changes...
We thought that we change DFM files to read only, but this can prevent the usage of SVN too...
So somebody please help us: have the Delphi some extension (like gexpert) that can lock the DFMs to avoid changes, and some other tool to see that dataset is used in other forms or not?
You're kinda cheating on Delphi. It is built to manage the duality *.pas and *.dfm altogether, knowing how to maintain the links (and with form inheritance, it's better to have all the stack open).
If you want to manually interfere, you have to know what you are doing and do it very carefully. You're not supposed to fiddle with the dfm insides more than to edit the form code portion before the private section.
What I do when I have to edit the dfm manually is to make sure it's not open in any way in delphi (beware form inheritance) and then edit it in another editor.
Also when I check the pas/dfm back in, I do a diff on the dfm to make sure nothing bad happened to it.