Jump to content

David Heffernan

Members
  • Content Count

    3500
  • Joined

  • Last visited

  • Days Won

    174

Posts posted by David Heffernan


  1. 1 hour ago, ŁukaszDe said:

    If IDE FIx Pack significantly reduced the compilation time of the project in XE2 and 10.2.3, it probably will do it also in 10.3 (the same project).

     

    In the subject:

    RSP-21934

    Assuming that the integration of IDE Fix Pack doesn't address compiler performance. Which it might. Or might not.

     

    Easy enough to compare 10.2 and 10.3 rather than guessing. 


  2. It is my experience that ignoring such defects in your code in the interests of saving time costs you more time in the medium term. 

     

    It is my experience that putting off investing in learning debugging skills in the interests of saving time costs you more time in the medium term. 

     

    I understand that your boss might not appreciate that. 

    • Like 1

  3. 14 hours ago, Kryvich said:

    @David Heffernan How you think: is RTTI information concentrated in one place of an executable file, or scattered around it? Open any EXE file and find the answer. I would prefer that the RTTI information be in a separate segment (resource) of the EXE file, and preferably in a separate file. But you are right about performance: it is better to test, and then draw conclusions.

    Perhaps I'm guilty of making assumptions. I presumed the RTTI was in a resource. 

     

    Still always best to measure. 

     

    FWIW I disable RTTI when I don't need it. 


  4. 1 hour ago, Kryvich said:

    As you know, modern Delphi versions add the RTTI information to the executable file. RTTI gives you the opportunity to do incredible things in your application. But it is not always necessary. You can disable RTTI in your application by adding the following lines to each unit:

    
    {$WEAKLINKRTTI ON}
    {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

    But to completely disable RTTI, you need to add these lines to used RTL units too, and rebuild the project.

     

    How much will the size of the executable file decrease? Well, I checked it on small utilities from the Delphi Localizer project, and here is the result:

    • kdlscan.exe was 742400 bytes, now 360448 bytes, -51%
    • lngupdate.exe was 727040 bytes, now 282112 bytes, -61% (!!!)

    The smaller size of an executable file means that the file is read twice as fast from disk. In addition, the processor is more likely to be able to fully fit your utility into its cache. You can give other reasons why this makes sense.

    Not really. The file is mapped into memory and then read from the disk when the virtual memory system encounters page faults. So if you don't use the RTTI it will never be read. 

     

    Don't theorise about performance. Measure. 


  5. 4 hours ago, pyscripter said:

    But here I am comparing the same app with/without debug dcus not between 32bit/64bit. 

    Actually I just noticed that the difference only appears with 32 bit in Delphi Rio.   Debug dcus make little difference in Rio 64bits or in Delphi Tokyo

    The surprising thing is that in this benchmark application, most of the computational time is spent inside external c code linked into the application.   Could it be that the debug dcus link to different c code in 32 bits Rio compared to dcus without debug info?

     

    Another finding was that in Delphi Tokyo, the benchmark runs significantly faster in 64bits than 32 bits  (quite the opposite with Davids zlib experience).

    My point is not that it's a 32/64 bit issue. My point is that it could be a difference in the way the C code is compiled. 


  6. You just have to extend the code to bring itself out of the tray as you say. Although strictly speaking it isn't in the tray and in fact the tray isn't even called that. It's a notification icon in the notification area. 

     

    What you mean by being in the tray is that the main form is hidden, Visible is false. So you just need to show it. Presumably you already do that when the notification icon handles being clicked. 

    • Thanks 1

  7. 3 hours ago, Fritzew said:

    Good Question, i have not seen any changes there. To be honest I was not aware of the GitHub fork. For my needs there was all there in sourceforge

    GitHub is not a fork. That is the master repo. 


  8. 2 hours ago, GreatDayDan said:

    I have checked out the code from GitHub, cloned the XE8 folder to XE10 and added the compiler code.

    The  GR32_R.dpk compiles.

    The GR32_D.dpk errors with "required package GR32_R not found."


    requires
      designide,
      vcl,
      rtl,
      GR32_R;

     

    I have included the new XE10 folder in the path.

     

    What am I missing?

    What is XE10? 


  9. 1 hour ago, Fritzew said:

    I have checked my Source, it is from Sourceforge http://svn.code.sf.net/p/graphics32/code/trunk

    I have done 2 Steps to compile it for Tokio

    1. Copy of package Dir XE8 do Tokio

    2. in the GR32_Compiler.inc added:

    
    {$IFDEF VER320}
      {$DEFINE COMPILERXE8}
      {$IFNDEF BCB}
        {$DEFINE DELPHIXE8}
      {$ELSE}
        {$DEFINE BCBXE8}
      {$ENDIF}
    {$ENDIF}

    Compile the two Packages GR32_Rxxxx and GR32_Dxxxx 

    Done

    Why wouldn't you get the latest source from the repo? 


  10. Scale it back to a small test program. As for what's wrong, the thing that keeps the window on top is the window owner property. In VCL that's known as popup parent.

     

    I know you want a quick answer but sometimes you have to work a bit. Make that minimal test program and the answer will be easy to find. 

×