Jump to content

Oboba

Members
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

3 Neutral
  1. Oboba

    RAD Studio 13 is available

    This would be an extremely bad decision. In my case, in different applications, the 32-bit exe works 30-40% faster than the same code, compiled in 64-bit. It seems that the 64-bit compiler is not mature enough in Delphi, optimization and generated code is not as good as 32-bit. I can also add a lot about compiling speed and debugging in Delphi 64-bit but I'm too lazy to type all this. So I hope the 32-bit compiler stays with us for many years to come. Bug part of my work is service applications for Windows Server and I ship all of them as 32-bit exes - speed and reliability is just so much better.
  2. Oboba

    New Delphi features in Delphi 13

    So the Refactor menu is greyed out, why is that? I know it didn't work properly sometimes, even basic "Rename" refactoring. I see above that it was removed with the Modelling support, then why leave the menu item greyed out and not remove it completely then?
  3. Oboba

    New Delphi features in Delphi 13

    I did it and have both versions 12.3 and 13 working.
  4. Oboba

    RAD Studio 13 is available

    Will do it after one week or so, previously it took about a week after new Delphi is released to have madExcept updated. Except that now the project seems to be not as alive as it used to be.
  5. Oboba

    RAD Studio 13 is available

    Does anyone know if madExcept is going to be updated to support this new Delphi version? Latest news on the madshi website is from 2023 and their forums are dead 😞
  6. I considered replacing madExept with EurekaLog but after doing some tests I have some doubts about the latter because of its CPU usage. The following screenshot from Process Explorer shows CPU usage for an executable compiled with different options and exception handling tools, the programs were left running for couple of hours. Configuration options for ME/EL are more or less default (production use - no mem or resource leaks checked etc). Screenshot lines explained: 1. madExcept x64 2. EurekaLog x64 3. EurekaLog x64, disabled: catch mem problems, fill freed mem, wipe stack on idle 4. No exception handling tool 5. madExcept x86 6. EurekaLog x86 I see that adding madExcept has virtually no overhead. And EurekaLog consumes a lot more cycles - what does it do? I tried disabling memory debugging potions, hoping that it was the issue, but turned out it was not. Isn't it supposed to do nothing when there are no exceptions?
×