Anders Melander

Yes, I understood that. My point is that searching for this pattern, which is a perfectly normal and valid pattern, would be premature optimization. If there is a performance problem in an application then you analyze the application (for example with a profiler) and locate the hot spots. It is then then easy to identify this pattern in those hot spots just by reading the code. You don't need a tool for that. It's like having a tool for identifying loops because loops are slower than no loops.

"Time limited license"... Thanks, but let's not. Also it seems they've opted to keep the map file info separate from the application. I guess that makes sense on mobile due to the size. Not so much on desktop.

It's not that hard to spot. Why would we need a tool for that?

I usually wait until after my morning coffee. Very good point. Few people enjoy watching paint dry - unless it's body paint I have "solved" quite a few performance problems simply by adding a splash screen and/or a progress bars.

Well, you shouldn't really be solving that by giving the application full access to everything - but that's a different issue.

On Windows you can use an exception logger such as MadExcept or Eurekalog. I don't know of any solutions for maxOS.

I have no idea about what that is. You cannot drag between applications running with different elevated privileges (e.g. run as administrator) so make sure that you aren't running Delphi elevated - or disable UAC.

There's no difference between ITE and BTM in that regard. They use the exact same RTL mechanism. Ie. the BTM and ITE resource modules are identical. It's only the localization editor/manager/compiler that's different. I believe LoadNewResourceModule used to be in the RichEdit example (no longer included with Delphi but you can find it on the net). Instead you can use LoadResourceModule, in the system unit, or my version of LoadNewResourceModule, in the amLocale unit of the BTM source.

Thanks. Please read the last part of the answer for info on controlling the active language: ...But be aware that once a form has been created (and thus the DFM loaded from the resource module) you will need to either recreate the form or reload it from the DFM resource (not recommended) in order for it to use the new language.

I believe you're thinking of the pfInKey value of TField.ProviderFlags. <rant>I know the help has improved but why the hell isn't there a link in the help from the ProviderFlags property to the type of the property. Don't they have computers that can do this stuff for them?</rant>

What do you mean? Can you rephrase the question, please.

That's a very short sighted attitude. Technical debt accumulates and your memory will not get better with age, or so I've heard

No I don't think so. You've just made your code more complex and harder to maintain and gained almost nothing.

Define "well" I'm pretty sure it can easily beat me. https://www.chessprogramming.org/Nero

There isn't really a "primary key" index on a TFDMemTable. You can have multiple indices on a table and one of them can be the "current index". http://docwiki.embarcadero.com/Libraries/Sydney/en/FireDAC.Comp.DataSet.TFDDataSet.Indexes I guess you can specify the soPrimary option on an index but I'm not sure if there's any practical difference from the soUnique option. http://docwiki.embarcadero.com/Libraries/Sydney/en/FireDAC.Comp.DataSet.TFDIndex.Options

...and no comments. Not a single one! It's almost as if the code was generated by a decompiler. Not that I think it was because then there would be comments

I think the primary strength of OpenGL is that it's portable. Coming in at a close second is the performance of 2D and 3D vector graphics helped by the fact that many operations are hardware accelerated. Of course this is only a benefit if you have a fast graphics card (otherwise it's a bottleneck), but the same can be said for Direct2D. I do not think that it can compete when it comes to raster graphics which I think is what Mike is asking for.

Why do you think that?

Seriously?

I think Apples revenue speaks for itself. Even though they make some really nice hardware it's obviously overpriced.

It's been a while since I did any comparisons of Graphics32 and GDI+ but AFAIR in the few cases where GDI+ came close to Graphics32 it did so at the cost of quality - e.g. fewer anti-aliasing levels or anti-aliasing via oversampling. To be fair the performance of Graphics32 comes at the cost of versatility since it only does 32-bit images. Graphics32 also has a steep learning curve. In those cases where GDI+ has a feature missing from Graphics32 I believe one can use GDI+ to draw on a Graphics32 bitmap via the bitmap handle.

The iterators were David's code and was just part of the test bench. As long as every solution uses the same test bench code then that doesn't matter much but when some solutions then replaces the test bench code to optimize the solution that invalidates the comparison.

Generally Graphics32 does everything faster but specifically you will need to clarify what operations you're asking about to get a usable answer.

While I don't question the timings I don't think these latest benchmarks are fair; The goalposts have been moved. It seems the first solutions were aiming at optimizing conversion of a single hex digit and the later ones are optimized for strings. Some have had the iterators replaced by classic for and some haven't.

That was my thought too but then again, apart from the challenge of it, it's kinda pointless trying to squeeze every last microsecond out of an ASCII HEX to ASCII BIN conversion. It would be more relevant for HEX to binary conversion. Maybe in this case. You can find plenty of examples out there which demonstrates that a LUT isn't always faster. For example: What's the fastest way to convert hex to integer in C++?