Jump to content

A.M. Hoornweg

Members
 View Profile  See their activity

  • Content Count

    447

  • Joined

  • Last visited

  • Days Won

    8

Posts posted by A.M. Hoornweg

  3. Posted

    Just now, Stefan Glienke said:

    Which does absolutely nothing since like XE7 or so when they fixed the $RTTI switch to be local to the current unit.

    I haven't ported the project group from XE to Sydney yet, for now the directive is needed for XE where it applies to all units that the compiler rebuilds.  I just wish Embarcadero had optimized RTTI for size from the very beginning and given us the choice wether to use it at all.  Having RTTI in your code offers possible attack vectors for reverse engineering etc.

     

     

  4. Posted · Edited by A.M. Hoornweg
    Added image

    45 minutes ago, Stefan Glienke said:

    This cannot be because XE already had extended RTTI.

    I use a RTTI-stripped version of the XE libraries since ages, because when I migrated from Delphi 2009 to XE my executable sizes also grew a lot.   That RTTI stripping is much easier to achieve with XE because the {$RTTI....} directive was still a global option then, so you don't need to patch any source files.  Stripping RTTI is now an integral part in my Finalbuilder build scripts.

     

     

    Edit: I have attached an image with the executable sizes. 

     

    All executables were compiled in "release mode" without any debugging info. All executables were compiled with  {$WEAKLINKRTTI ON}  and {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}  in the DPR.

     

    (1) Compiled with XE10.4.2 Sydney.

    (2) As (1), replaced unit "Oleserver" with a dummy unit so no unnecessary VCL code is pulled in. 

    (3) As (2), using a RTTI-Stripped RTL/VCL.

    (4) Compiled with Delphi XE, replaced unit "Oleserver" with a dummy unit so no unnecessary VCL code is pulled in. 

    (5) As (4), using a RTTI-Stripped RTL/VCL.

     

     

     

     

    code size.png

    • Like 2

  5. Posted · Edited by A.M. Hoornweg
    fixed a typo

    Hello all,

     

    in my quest to port a very large project -containing dozens of COM DLL's- from Delphi XE to Sydney, the main obstacle for me was the exploding executable size.  Each and every DLL in my project group had grown between 1-4 megabytes and that really added up painfully.  Most of that growth, of course,  is due to the new extended RTTI (which I do not use).   The project was already huge before, and a doubling or tripling in size would cause deployment problems (the software is used on oil wells on remote locations and bandwidth is often costly and slow).

     

    Trying to strip off some MB's wherever I could, I started studying the MAP files to make sure no unnecessary stuff was linked in.

     

    I noticed that all of my non-visual COM DLL's nevertheless pull in huge chunks of the visual VCL, including units VCL.Forms, VCL.Themes, VCL.Imagelist etc.  I am absolutely sure that I don't use these routines anywhere and still they make up over 60% of the executable's code! The underlying cause is that all of the xxxx_TLB.PAS files, which the IDE auto-generates,  use a unit called OleServer which has an initialization section. No code in the unit itself is called, but the initialization section manages to pull in most of the VCL for whatever reason.

     

    As a test, I made a dummy unit "oleserver.pas" and referenced it as the first file in my COM DLL applications. The project compiled fine, and this change alone instantly reduced executable size with a whopping 1 MB.  And the best thing, the project still worked as expected. So it seems to me that this whole OleServer unit is an unnecessary thing in my projects.

     

    Another thing. When I link my projects against a "stripped" version of the RTL/VCL (recompiled without extended RTTI), the size difference becomes astronomic.   My DLL's have now typically lost 80% of their size, going from 2MB+ to only 400kb.   With these executable size reductions I am finally able to port this project to Delphi Sydney.

     

     

     

    I am in the process of writing a tool to automate the "rtti stripping" of the RTL/VCL which I plan to release as open source.  For example, projects like "inno setup" might benefit from it. 

     

     

     

     

     

     

     

    • Like 5

  6. Posted

    15 hours ago, dummzeuch said:

    Yes, thats how a SpinLock is supposed to work, isn't it?

    The purpose of a spinlock is to obtain the lock as quickly as possible.   On a single core system, doLock should yield on contention because the thread that owns the lock is waiting to be resumed.  On multi-core systems it can keep spinning.  

     

     

    In the initialization of the unit, call GetProcessAffinityMask() and count the bits in the integer to obtain the number of cores available to the program. 

     

     

     

    • Like 2

  9. Posted

    Hello all,

     

    I see that Delphi supports both bitwise and logical versions of and/or/xor operator overloading, but I'm not 100% sure about the difference between the two concepts. 

    Assume I have a certain record type, and that I want to implement "AND", "OR" and "XOR" operators, each resulting in some kind of merge of the original input records.  The syntax I would like to use in my code would simply be "A:=(B OR C);"   

     

    Do I need to implement BitWiseOr etc or LogicalOr, and if I implement both, how does Delphi decide which of the two is going to be used?

     

     

  10. Posted

    2 hours ago, David Heffernan said:

    I can't believe that anybody would use such code in real programs. Wouldn't it just be better to initialise your local variables?

    Generally, yes.  But it would also be great to have a nifty tool at my disposal that lets me wipe all locals on the stack with a single call, especially if it is a complex routine with lots and lots of local vars. In such cases it would simply save a lot of boilerplate code.  Delphi does the very same thing for class members and I would totally hate it if it didn't.

     

    I had hoped that this would be a trivial thing to write,  since all StdCall procedures start with a byte sequence like "mov ebp,esp; add esp, -sizeof(localvars)". 

  11. Posted

    4 minutes ago, David Heffernan said:

    I can't believe that anybody would use such code in real programs. Wouldn't it just be better to initialise your local variables?

    Normally yes. I only asked because I overlooked initializing a certain local variable and the compiler (Delphi XE, which is used in that specific project) didn't warn me.

     

    OTOH, if Delphi takes the trouble to zero-fill managed local variables anyway, it puzzles me why it does not simply fill the rest as well. A REP STOSD is lightning fast.

     

  13. Posted

    Hello all,

     

    is there a way to quickly initialize all local variables of a procedure with zero, maybe using FillChar?  It would be very practical to use at the beginning of a procedure.  I had a case recently where the Delphi compiler didn't throw a warning when I accessed a local variable before it had been initialized and it had me debugging for hours. 

  15. Posted

    6 minutes ago, David Heffernan said:

    But the reference counting is interlocked, and I'm sure it's there for a reason, and I'm sure that I've forgotten what that reason is.

    The reason is, that when S goes out of scope, it decrements the reference count of G. 

     

    G should only be destroyed when its reference count reaches zero so that action must be atomic.

     

     

  16. Posted

    11 hours ago, Mike Torrettinni said:

    So, I assume this is quite rare to find in real code.

    That may very well be true. 

     

    But when a developer is doing refactoring to make code more legible and concise, IMHO it is a good thing if the parameter list reflects the intended use of the parameters.  So if a parameter is intended just for outputting something and not for modifying an existing value, the "out" modifier is clearer than "var".

     

     

    I find "const" parameters confusing at times, especially when passing stuff like arrays. If I pass an array as a const, am I supposed to be able to modify elements or not?   The Delphi documentation (link at he bottom) says "... constant parameters are similar to value parameters, except that you cannot assign a value to a constant parameter within the body of a procedure or function..." . 

     

    I don't want to nit-pick, but I find it very confusing and counter-intuitive that I can modify the array in such a case.  

      

    Type tintarray=tarray<integer>;

Procedure dosomething (CONST a:tintarray);
var i:integer;
begin
  for i:=0 to high(a)-1 do
    a[i]:=random(maxint);
end;

procedure TForm1.Button1Click(Sender: TObject);
var x:tintarray;
begin
  setlength(x,10);  //newly allocated space is set to 0
  dosomething(x);
  showmessage(format('%d',[x[0]]));
end;

     

     

     

     

     

    http://docwiki.embarcadero.com/RADStudio/Sydney/en/Parameters_(Delphi)#Constant_Parameters

  17. Posted

    16 hours ago, Rollo62 said:

    I would disagree to that, because a compiler should understand that by ref and by value of the same value is requested,

    Unlike "shortstring", Delphi cannot pass managed types such as strings by value.  It is always a pointer.  

     

    I'm not 100% sure but I think an "out" parameter is like a "promise" to return a value no matter what, and also a promise not to use it for input. The problem being that it is possible to pass the same variable twice and thus circumvent the no-input promise.

  18. Posted

    42 minutes ago, Rollo62 said:

    Is there any argument why this is correct ?

    "Out" parameters of managed types (such as strings, interfaces, dynamic arrays) are initialized before a method is called. 

     

    The problem only arises because multiple parameters in the method reference the same string.  The behavior is correct but very counter-intuitive. It would behave more intuitively if the compiler would issue a UniqueString() for the second/identical parameter.

  22. Posted

    On 1/3/2021 at 2:50 AM, Mike Torrettinni said:

    Interesting how such a simple const vs non-const usage can be the cause of issues.

    "Out" parameters are an even bigger can of worms.

    I had refactored some code recently to use "OUT" parameters instead of VAR parameters (in order to more clearly document the intended use) and it had side effects that were hard to figure out. I thought my debugger had gone bananas.  Try single-stepping through this code and watch the values. 

     

    In hindsight, the cause is clear, but I find the compiler should throw a warning if it encounters such a situation.  I now avoid OUT parameters.

     

      

    procedure tform2.test(OUT somestring:String; Defaultvalue:String);
begin
  Somestring:=Defaultvalue;
end;


procedure TForm2.Button1Click(Sender: TObject);
var t:string;
begin
    t:='Testing 1-2-3';
    Test(t,t);
    Showmessage(t);
end;

     

    • Like 2

  24. Posted

    On 12/19/2020 at 10:01 PM, alogrep said:

    No. It's a huge project and I can't compile it. It used to compile fine .  

    Did you install any software or packages recently that changed your system's "path" variable? 

     

    The Windows PATH variable has a limited maximum length. If setup routines keep adding entries to it then it may get truncated and all sorts of things on your system stop working properly. Like Delphi not finding its installed BPL's anymore.  Happens to me all the time.

     

    Some component manufacturers (like TMS) store BPL's in non-standard locations and that regularly causes me headaches for this reason. I really wish component manufacturers would stop doing that. 

  25. Posted

    On 12/18/2020 at 8:10 PM, c0d3r said:

    We were using 3rd party TPngImageList to store all PNGs. Do we have to prepare different set of Images in order to make images working under different High DPI? 

    My current approach is to store all *.PNG files in high resolution inside the resources.  I scale them down to the appropriate size when the application starts and the display resolution is known. I use my own scaling routines (using a Lanczos2 filter) but there are lots of libraries that can do the same thing.  

     

    This approach does not solve the situation of the user having multiple screens in multiple resolutions though.

    • Like 1
×