-
Content Count
3500 -
Joined
-
Last visited
-
Days Won
174
Posts posted by David Heffernan
-
-
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:
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.
-
35 minutes ago, ŁukaszDe said:Without IDE Fix Pack projects compile twice as long.
You can't know that because IDE Fix Pack does not exist for Rio.
- 1
-
-
6 hours ago, dummzeuch said:GExperts also uses InnoSetup. So far there are no problems that I am aware of.
Does that do msi?
-
That value is as good as any other value. It just has to adhere to the rule that the same value is returned every time when the same input value is supplied.
- 1
-
No such thing as EU decimal behaviour. Different countries in the EU have different locale settings.
- 1
-
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.
- 1
-
This problem could readily be solved if you let us help you learn how to debug it.
-
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.
-
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.
-
Heap corruption in code we can't see. Make a minimal reproduction.
-
52 minutes ago, mausmb said:Solved with Frac !
wsInvoice.TimeTransaction.AsUTCDateTime:=Frac(tblInovicesTimeTransaction.AsDateTime);
br,
Marjan
Doesn't seem like that's a real solution.......
-
The point is that faster memory allocation treats the symptom rather than the cause. Such a large boost in performance implies that memory allocation is dominating execution time, at least in this benchmark.
That in turn implies that reducing the amount of memory allocation could give far greater boosts.
-
Doesn't this suggest that reducing the amount of heap allocation would lead to much bigger gains?
-
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.
-
Is it possible that the difference is due to the PCRE code being compiled with poor settings?
Something similar to this: https://stackoverflow.com/q/27821277/505088
-
My understanding has always been that debug dcus are compiled with optimisations etc. and so there should be no performance difference.
Can you provide a cut down program that demonstrates the issue?
-
17 minutes ago, swierzbicki said:It would be nice to ellaborate a little bit more !
What are your problems ?
Usually in this scenario one would prefer to get on with the job rather than spend time explaining the issues. I'm sure that if @dummzeuch would like some help he know how to ask.
- 3
- 1
-
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.
- 1
-
You write a zero byte beyond the end of the char array. Solve the problem by using Move to perform the copy.
- 1
-
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.
-
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?
-
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?
-
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.
Strange thing in System.Generics.Defaults.pas
in RTL and Delphi Object Pascal
Posted
Why not 10101010? Or 1010101010? Or 1010? Or 10?