dummzeuch

Yeah, right. Think again, Thomas. I did some tests and it turned out that in these tests(!) on my computer(!) Sleep(1) increased the throughput by more than 50% over Sleep(0), even though all threads were running in the same application and with the same priority: Sleep(0) 5 Writers 5 Readers Run1: Writes: 5738 Reads: 4683 [avg. per ms] Run2: Writes: 5662 Reads: 4716 [avg. per ms] Sleep(1) 5 Writers 5 Readers Run1: Writes: 10444 Reads: 7528 [avg. per ms] Run2: Writes: 8587 Reads: 9411 [avg. per ms] Note that it is quite possible that I bungled the tests. They are not as consistent as I would have expected.

Actually I did less than a year ago: Compiling TeeChart 2020 for Delphi 2007 It won't help, of course.

Unfortunately many well known commercial and open source libraries don't adhere to these. It's a major pain in the lower back every time I want to install Delphi on a new computer (which happens quite regularly, at least several times per year).

... or simply assume a multi core system. When was the last time you saw a single core (Windows-) system in the wild? OK, a program could be restricted to a single core by the user or the OS, so there is that. And there are VMs which can also be configured to run on a single core even on a multi core system.

I'm writing my own spinlock to get a feel for what can be done. One of my programs shows some odd behavior when using a critical section so I tried to see whether this changes when switching to a spin lock. It seemed to work at first, but my last test failed miserably so I'm "going home" now. Quite possible, but since these require API calls, they have a significant overhead in the best case (no spinning required). I knew about Sleep(0) vs. Sleep(1), but wasn't that supposed to be changed in Windows Vista and later? (reading the second link) OK, apparently not. But since the threads in question are running with the same priority, Sleep(0) should work fine. Apart from that: the above code was just an example, how to prevent running a single CPU system at 100%.

You mean instead of Sleep()? I haven't thought much about that case yet. Using doTryLock it with sleep which gives a much higher throughput than doLock or a Critical Section in my tests on my computer. But I am not yet sure whether this makes any difference in a real world scenario. Apparently there the is the Pause instruction on Intel CPUs: https://stackoverflow.com/questions/4725676/how-does-x86-pause-instruction-work-in-spinlock-and-can-it-be-used-in-other-sc I'll have to look into it.

Yes, thats how a SpinLock is supposed to work, isn't it? That's why I added the doTryLock function which could be used like this: while not doTryLock(Lck) do Sleep(0);

Does anybody else have this compile error?

Hm, that's odd: I just checked out the sources to a new directory and run the build script. Compiled fine. (Bloody license server is acting up again, so I can't load it into the IDE right now.)

Oddly enough, the file is right there: In Directory Source\UsesExpert: (Maybe it doesn't really belong in this directory because it's used by a unit in framework) I'm not sure what causes the compile error, but I will investigate. Did you compile in the IDE or via the build script?

Not the genie, the GExpert 😉

Please no discussion about Covid here.

I just committed a dproj file for Delphi 10.4 (GExpertsGrep.10-4.dproj) This works for me. The automatically converted Delphi 2007 dproj file didn't work for me either.

Ouch! Wtf did they declare it public in TCustomEdit? Most not-yet-published properties of other components are declared protected. But there are exceptions there too: TCustomLabel.Caption is also public. Why? (Yes, I know, I won't get any definite answer here unless some Borland employee talked about it in the 1990s.)

Does anybody know how to prevent the ExplicitTop/Left/Width/Height properties from being written to the DFM file? I never saw any use for them and always installed Andreas Hausladen's DDevExtensions which allows to remove them. But since Andy apparently doesn't have access to the latest Delphi version there is no DDevExtensions (and also no IDE Fix Pack) for Delphi 10.4(.1) and I would like to add that functionality to GExperts. I tried, but so far failed. Any hints?

I always compile that tool with Delphi 2007. I currently can't test whether it compiles with Delphi 10.4 due a a connection problem with the license server. I have only seen that with Delphi 2007 before. It happens every time a Windows update deletes the files that the Delphi 2007 installer put into that directory. After I copied them back and everything compiled normally.

... and other older posts in this topic.

Hey, I am the German here (*1). But now you sound like one. 😉 Spoilsport! (*1: Of course I am not the only German here.)

You won't have any functionality introduced in TEdit, only the one in TCustomEdit and whatever you implement yourself in TMyEdit. That probably was obvious. 😉 If you declare the property as public, it won't show up in the Object Inspector. For that it needs to be published.

You forgot one important reason to optimize: The pure fun of it. 😉

By default the IDE enables optimization and disables Range checking and Overflow checking. I've always found that odd, because I want the best possible compiler support for debugging which means: Optimization off Range checking on Overflow checking on

I need to set a double variable in a thread safe manner. I could, of course use some synchronization object, e.g. a critical section, but on the other hand there is InterlockedExchange64, which sets the contents of a 64 bit integer variable, and a double is also 64 bits, so I thought this should also be possible in the same manner. Unfortunately that function, while described as part of the WinAPI, doesn't seem to actually be a WinAP function but implemented as a C macro in winnt.h and in assembler in Delhpi 10.2. Google found DsiInterlockedExchange64 in the OmniThreadLibrary unit DSiWin32, which implements it in assembler for Win32 and Win64. I took that code and came up with the following for atomically setting a double variable: procedure InterlockedSetDouble(var target: double; Value: double); asm {$IFDEF CPUX64} lock xchg [target], value mov rax, value {$ELSE} { -> EAX target } { ESP+4 value } PUSH EDI PUSH EBX MOV EDI, EAX MOV EBX, DWORD PTR [value] MOV ECX, DWORD PTR [value+4] @@1: LOCK CMPXCHG8B [EDI] JNZ @@1 POP EBX POP EDI {$ENDIF ~CPUX64} end; { InterlockedSetDouble } I am for now only interested in 32 bit Windows where this seems to work, but being far from an assembler expert, I wonder whether I might be missing something.

Did you test it? Since access to 32 bit aligned memory is faster, it's quite possible that the compiler generates code that aligns all parameters, regardless of size (I didn't test it either though). But the parameter target might not be aligned. That depends on what is passed into that procedure.

Maybe PasDoc?

Yes, he is correct. I had to restore those files several times after a Windows update. Not sure whether that's a Microsoft/Windows or a Borland/Codegear/Delphi 2007 problem. Are we supposed to add additional target files to the dotNet installation directory?