Forum > LCL

[SOLVED] Improvement of TApplication.GetControlAtPos

<< < (2/2)

lagprogramming:

--- Quote from: TRon on August 25, 2023, 05:29:18 pm ---So the fixes seem to become more and more a personal preference matter (as the posts above is mine), which is not suggesting to stop posting these kind of things as they are sometimes interesting approaches and mostly do matter, as for instance in this case preventing the double compare.

--- End quote ---
Both your code suggestions avoid the useless "if Assigned(Result) then" double check, which is fine. My proposal was based also on FPC's recommendation on arranging if/then/else code, but that's not very important for LCL. You can propose the two versions in gitlab so there would be 3 versions to choose from :).
This is the subject of interest.
If the readability of the source file is not significantly reduced, are LCL developers interested in decreasing the number of conditional jumps? The only official answer is by proposing patches for a couple of routines. If the patches are accepted in the development source files then the answer is yes.
Some might consider that avoiding a single conditional jump in a routine is something insignificant. Well, looking at the routines in official source files I estimate that most of them have less than 10 conditional jumps, on average, which means that removing even a single one is a reduction of minimum 10%. For old CPUs and low powered devices that may be noticeable and measurable, especially when the conditional jump is removed from a while/repeat/for loop. MSEgui has very efficient code with very few useless conditional jumps(branches) making it very responsive.

Navigation

[0] Message Index

[*] Previous page

Go to full version