Anders Melander

It doesn't need to be, FTOH you can use the low bits of the pointer as a spin-lock flag. That's rather condescending. It's not that I'm not comfortable with it. It's just a solution I personally wouldn't use. I would say that what constitutes "good" is subjective and not defined by "because it is".

Not really. It's not the loading of the EXE that takes time. It's the application startup, login, select various application stuff, navigate to the POI, etc. Imagine if you were developing the Delphi IDE and was working on some problem that could only be reproduced with a specific project. How long time does it take to start the IDE, load the project, etc.

Not in this project. It's a C/S desktop application and there hasn't been a need for logging. No, what I'm talking about is the compile, debug, edit cycle.

I'm often working on applications where it can take 5-10 minutes to launch the application and navigate to the point of interest. Hot reload could save me hours every day.

The critical section is only an object because Embarcadero chose to make it one. It doesn't need to be. A spin lock is virtually costless and does not require any instantiation. Works, yes, but I beg to differ on the good part. It's not a pattern I would use. Too "clever".

Yes, I already acknowledged that. Having a Rudy moment?

Yes, but you can't use TMonitor without an instance which is exactly when we need it. A simply spinlock would probably be the cheapest in this particular case, but my example was just to illustrate what I meant. Keyword here is Lazy

Got it. No race condition then. My point was that since the code instantiates an object it isn't as lockless as it appears. The locking being performed is just out of view. A critical section would be much cheaper - and in plan view. var HelperRegistryLock: TCriticalSection; InternalHelperRegistry: IHelperRegistry; function HelperRegistry: IHelperRegistry; begin // Once InternalHelperRegistry has been assigned no locking occurs if (InternalHelperRegistry = nil) then begin // Locking here only happens when there's a race to create the instance HelperRegistryLock.Enter; try if (InternalHelperRegistry = nil) then // Locking inside MM only happens here - a single time InternalHelperRegistry := THelperRegistry.Create; finally HelperRegistryLock.Leave; end; end; Result := InternalHelperRegistry; end; initialization HelperRegistryLock := TCriticalSection.Create; finalization InternalHelperRegistry := nil; HelperRegistryLock.Free; end.

The possible race condition I referred to has to do with the (presumably reference counted) lifetime of InternalHelperRegistry but since I haven't looked at the rest of the code there might not be a problem - for example if InternalHelperRegistry is guaranteed to stay alive elsewhere. With regard to locklessnes, doesn't the instantiation of an object cause a lock in the memory manager?

Why? One is a compiler. The other is not(-ish).

Yes it does seem to come from that SO thread. The problem as I see it is that it mixes a lock free solution, that's meant to operate on pointers, with reference counted interfaces. Also I don't like the practice of creating an object and then freeing it if it's not needed anyway, but that's besides the point.

Doesn't look thread safe to me. I haven't looked at the code apart from the snippet you posted, but as far as I can see there's a race condition.

Yes. I'm not using that project at the moment so I haven't kept it up to date.

No doubt but not by that much. I would guess it would be about 25% faster than TBitmap.ScanLine. I.e. around 45 mS on my system. My point was more that it's not really fair to benchmark anything against TCanvas.Pixels since it's known to be dead slow. It's more of a convenience feature. Without having profiled the code I think the TBitmap.ScanLine implementation mostly suffers from the overhead of the call to GdiFlush inside TBitmap.GetScanLine. Since the original implementation writes the bitmap in X-Y order I duplicated that in order to be fair but this also means that the TBitmap.ScanLine implementation performs Width*Height calls to GetScanLine and thus GdiFlush. I circumvented this by caching the scanline row pointers in an array (without this it would have been slower than using TCanvas.Pixels). The X-Y order also means that each pixel write trashes the CPU cache - It should be significant faster in Y-X order.

The version I use works. I don't have time to check the difference in how we do it but you can see for yourself if you want to: https://bitbucket.org/anders_melander/dwscriptstudio/src/15b205a8a7b4d461b786452aa4e0ee548779fe92/Source/amScriptDebuggerMain.pas#lines-1184

I would guess that the override is based on the message number but it should be easy to determine; Just try it.

The omission of brc32.exe is probably an installer bug Use brcc32.exe instead or better yet, use the MS resource compiler rc.exe

I just did: TCanvas.Pixels: 320 mS skia4delphi: 130 mS TBitmap.Scanline: 60 mS

Here's a C implementation: https://github.com/yparitcher/libzmanim The code looks well written.

You could roll your own: https://en.wikibooks.org/wiki/Computer_Programming/Hebrew_calendar Here's some code but I have no idea about what language that is: http://www.chelm.org/jewish/calendar/algorithms.html

https://docs.microsoft.com/en-us/windows/win32/com/activex-controls-registry-information You can add the 16x15 bitmap to your Delphi project using Project > Resources and Images. Searching the Delphi source for "ToolboxBitmap32" I can see that TActiveXControlFactory has a ToolboxBitmapID property which you can use to specify the resource ID of the bitmap. The value of this property is written to the registry when the ActiveX control is registered. A .dcr file usually just contains the Delphi design time glyph of a component - I.e. the glyph you see on the component palette in Delphi. It has nothing to do with ActiveX controls.

https://en.wikipedia.org/wiki/Law_of_triviality

Exactly. It's pretty pointless to suggest different ways of doing conversion if the conversion will be done with TryStrToFloat, StrToFloat or the like. And it's even more pointless when this is in all likelihood premature optimization.

The only built-in way to determine if a string can be converted by TryStrToFloat is to use TryStrToFloat. You could reverse engineer TryStrToFloat to make a version that only parsed the string and didn't actually do the conversion but my guess is that the majority of time used by TryStrToFloat is used by the parser, not by the conversion. But if you are reading from a text file then it's likely that the I/O will be your real bottleneck and as David hints at, you should profile first and optimize next.

It depends on what you mean by "can be converted to number". If your definition is that TryStrToFloat returns True, then the answer is no. If you're willing to give up some of the features of TryStrToFloat then the answer is yes, but you are going to have to implement it yourself - in assembler. But why do you need it to be faster? Is it a bottleneck for you?