I'm working on migrating an old project from Delphi 2007 to Delphi 2010. One thing I've found is that the resulting executable has more than doubled in size, and the original was already quite big. (Over 50 MB.) I suspect that a lot of it has to do with extended RTTI.
Since the project predates Delphi 2010, it doesn't use extended RTTI anywhere, and I'd like to be conservative about including it. Is there any way to use the Project Options dialog to globally set {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} as the default? I'd have expected there to be an option for this (and for $WEAKLINKRTTI) somewhere, but I don't see them.
Does anyone know if this can be done from the "Additional options to pass to the compiler" field, or some other way? I'd really prefer not to have to add an include file to every single unit in the project, as there are a few thousand of them...
The behavior of the $RTTI directive has been changed since XE6 because actually it was a bug because it was supposed to be local to the current unit (and it was actually documented as that since Delphi 2010).
Also it could have fatal affects using the directive at all even in one unit because due to the bug it basically switched a global flag affecting the following units (as in the order of compilation).
You can try with the dcc32 –$weaklinkrtti command-line option. (like {$WEAKLINKRTTI ON}).
But that has not the impact of {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} in each unit.
Your best bet would be to have it at the top of each unit in an include file.
But then it wouldn't do it for the VCL/RTL which would still be inflated....
Update: Also make sure you compare what's comparable. For instance verify if you don't include debug information in the Linker Options in the new D2010 project where you may not have it in the D2007 one...
In a comment on Mason's own blog, in response to a comment of mine, Mason answered this question.
Try putting these two lines at the top
of your DPR, before the USES clause:
{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
This will make sure that no RTTI gets
generated for your own code or any
third-party libraries you use, unless
they’re in a unit where RTTI
generation is explicitly enabled. You
can’t turn it off for the RTL or VCL,
but that shouldn’t add very much to
your size anyway.
Are you certain this is caused by the new RTTI info? While it's a lot of data it shouldn't really double the size of your application.
Check that it's not including debug info in the release build executable.
(Project options -> Delphi Compiler -> Debug information should be False)
As for the question, I use {$WEAKLINKRTTI ON} before the uses clause in the dpr file and it seems to work fine.
I don't know of such an option, but I still would use an include file.
I wont be a problem for any experienced Delphi programmer to write a small program to add an {$i ProjectIncludeFile.inc} to any unit in your folders (immediatly after the unit line).
And that way you can use it for whatever purpose you like.
I myself use if f.i. to set a WriteTempFiles compiler directive (which I use f.i. to save stringlist contents at various places when developing the program), that way I can disable it in one place when the program is ready for deployment.
Since most of my projects involve multiple executables and/or dll's, this is the easiest way to accomplish this globaly for the whole project.
Related
We're in the process of moving out Delphi XE2 apps over to Delphi XE5 (We have a window :) )
I'm wondering whether, as part of the move, I should be thinkning of adding my own Unit Scope to our internal applications. This question suggests that it's just of case of renaming units as Company.Unit.
Is it as simple as using Rename in the Project Manager?
Am I missing anything?
It's nearly that simple. You can use the Rename action in the project manager and that will rename the file, give the unit a new name, and change references in the .dpr and .dproj file. But that will not rename any references in code.
So, if you list the unit in uses clauses (seems likely that you will), or use the unit name to resolve ambiguous scope, then you will need to change the names there too.
If you don't have too many units it won't be very difficult to make the change in the project manager, and then fix all the errors that the compiler throws at you. If you have a larger project then you may be better scripting the change. I expect that you could go 99% of the way there with a simple regex based script that did the following:
Update references in the .dpr and .dproj files.
Change the file names and the unit names.
Find the uses clauses (interface and implementation sections) and update references there.
This would leave you to deal with the uses that perform scope resolution and my guess is that there would be few enough of these to let the compiler find them all.
I use a great Tool from http://www.easy-ip.net (DELPHI UNIT DEPENDENCY SCANNER) for that task.
You can change the Name of the unit and the DUPS change all your uses clause's.
How to automatically remove unused units from uses section on all source files of the project on Delphi XE2?
P.S. IDE will work much faster after that.
There is no way to fully automate this.
There are a few tools I'm aware of that take a wizard approach:
CnPack Uses Units Cleaner
Peganza's Pascal Analyzer (and it's sidekick icarus).
The Lazarus IDE has a "Unused Units" dialog in it's CodeTools package.
Peganza's tools simply show a report. CnPack will prompt to remove the unused units for you but you must confirm. Lazarus presents you with a list of unit's it thinks are unused and gives you the choice of removing some or all of them.
Why isn't it automated?
Because this is static analysis. Even the most sophisticated tools cannot determine with 100% certainty whether a specific line of code will be used at runtime let alone an entire unit. These tools have implemented their own parsers to accomplish this feat but they aren't fool proof.
In any case the main benefit of cleaning up the uses clause is removing visual clutter from both the source itself and the code completion feature. Yes there is some performance gained during compiling and certain IDE background operations will speed up slightly but I think you'll be disappointed if you think the IDE will miraculously speed up.
You'll see better IDE and compiler performance by:
Breaking your projects into smaller pieces that can be worked on independently.
Eliminating duplicate code.
Disabling unneeded IDE packages.
I'm certainly not trying to dissuade you from removing unused unit references. As I said it will help unclutter your source. Just make sure you're doing it for the right reasons.
We have a utility called the Delphi Unit Dependency Scanner (DUDS). It scans your entire project and builds a fully searchable tree of the units and dependencies. It can be very useful in finding unused units.
The application is Freeware and you can find it here.
Disclaimer-I am the author.
Don't think I would want a tool that would automatically rip out unnecessary units in the Uses section...
but there are tools out there to identify them...look at Icarus...freeware that you can get at http://www.peganza.com/downloads.htm
CnPack has "Use Cleaner..." option that I have used unit by unit basis without a problem. It also has the ability to do the entire project - which I haven't tried due to the size of the project.
Use reFind.exe utility provided since Delphi XE, use this command
reFind *.pas /X:unuse.txt
And unuse.txt is a text file with something like this:
#unuse Unit1
#unuse Unit2
#unuse Unit3
And that's it. It will remove the units in the uses clause taking care if the unit is the last one used and there is a ; after the unit.
I need (to make some quick and dirty tests) to modify the code of Variants and SysUtils.
What I need to do to "compile" the changes?
I can of course open those units in the IDE, but if I change them and I buoild a project again I don't see those units recompiled.
What is needed to be done?
The problem is you would need to compile ALL of the RTL/VCL against the 'new' units.
Instead modify a copy of the units in question and add them to your project when you want to use them. Delphi should use these over those in the RTL/VCL.
Unless you do not change the interface part of the unit (that is, you only modify the implementation side), you can make your own version of the RTL units (only exception is System.pas and SysInit.pas, but this is not in your scope - see our blog site for some enhancements of those units).
What you need is to put your own version of Variants.pas and SysUtils.pas in the search path of your project. They will be taken in account instead of the default RTL.
But be aware that you may easily break anything.
For testing purpose, this is OK, but if you want to use those modifications, you shall better use some automated regression tests, and know explicitly what you are doing.
Please note that you can use the "debug" version of the RTL units (from the project options), then step with the debugger within the official source code. It may help finding issues without touching the source.
If you change the interface part of the unit, you'll have to recompile all units which call the modified unit - for SysUtils and Variants, this is almost all RTL.
Delphi runtime DCUs are precompiled. It would be a waste of time to compile them at every build.
If the code you are trying to modify is a method of a built-in class, then a class helper may help:
http://docwiki.embarcadero.com/RADStudio/en/Class_and_Record_Helpers
So the question is which part of code do you want to modify in the runtime?
If you really wish to recompile the RTL you can do so (Make a backup first!). Versions of Delphi prior to Delphi 2010 had a makefile in the source folder that could be run from the command line to rebuild the rtl/vcl. I don't know for sure (I'm still using D2009) but from what I've heard this file is no longer present in newer versions. Hopefully there is an alternative. Otherwise you would wind up wasting a lot of time trying to guess that the compiler settings for each unit.
If you wish to "patch" a bug in the rtl for your project only you can copy the unit you want to modify into your project's folder and make your change. If the unit your modifying is used throughout the RTL/VCL you may find yourself copying quite a few dependent units into your project folder in order for it to compile.
If this significantly slows down the compile time for your project you can always do your initial compile then remove the "patched" units, leaving behind the compiled dcus.
In this question (link) it was said that the line below (in each unit) would remove as much RTTI as possible:
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
The posting didn't mention what Delphi version it works with, but I assume D2010. However, when I include the line above, I get this error:
DCC Fatal Error: E2158 System unit out of date or corrupted:
missing TVisibilityClasses.
I'm using a "stock" version of D2010 and have never done anything that I'm aware of that would change the default installation or the libraries.
Any suggestions? TIA
Related question: link.
Make sure you put the "{$RTTI" line below the "unit unit1;" line.
Note that as of XE5 and newer, this directive needs to be in each individual unit for which you want to disable RTTI. Before that (as in comments, which applies only to XE4 and below) it could be in the DPR file and would apply to all units in the project.
The new RTTI is for Delphi 2010 and up.
It can be removed, but then lots of things will have limited functionality (like JSON conversion, part of DataSnap and many of the newer 3rd party libraries that do ORM or other mappings).
Things depending on TValue are gone anyway.
"old style" RTTI (which was introduced in Delphi 1 and is still present in Delphi 2010) cannot be removed.
So: it is recommended to remove RTTI only from your own units, and not from the RTL and VCL.
--jeroen
i have use delphi xe recently but exe size is very big because of rtti(i think)
howto remove rtti , and can i make my application size as small as delphi 2009 application(490 kb) without comprssion; and what is the use of rtti
In short (full story provided by links in the splash's answer):
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
Note that as of XE6 and newer, this needs to be in each individual unit for which you want to disable RTTI. Before that (XE5 and below) it could be in the DPR file and would apply to all units in the project.
Read the Online Help for Delphi ...
Working with RTTI
RTTI directive
... and search Stack Overflow:
Why should I care about RTTI in Delphi?
Practical usage for Delphi's new RTTI
Keep in mind that the $RTTI directive has to be included in every unit where it should take effect. See How can I set the $RTTI directive for the entire project?
Your problem is not related to RTTI. If you are talking about relatively small increase (100-200K), this is due to extra functions in RTL (added for Unicode support etc). If you get 500-700K increase or so, then check whether you link VCL UI units (Forms, Controls etc). If you get 3Mb increase, then you've turned on extra debug symbols.
It's because some generics functionality has been added to sys units.
Generics were added in 2009 but in systems units some classes were rewritten with generics in xe and xe2. imho
Add this flags to reduce the size in dpr file (Project > view source) to each individual unit (as of XE5)*.
{$SETPEFlAGS IMAGE_FILE_DEBUG_STRIPPED or IMAGE_FILE_LINE_NUMS_STRIPPED or
IMAGE_FILE_LOCAL_SYMS_STRIPPED OR IMAGE_FILE_RELOCS_STRIPPED}
{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
(*) Note that as of XE5 and newer, this needs to be in each individual unit for which you want to disable RTTI. Before that (XE4 and below) it could be in the DPR file and would apply to all units in the project.
I do not think it is RTTI what adds so much size overhead to your application. How do you know it is?