Lars Fosdal

/blush

I would expect the hash generator you apply to your key would be pretty significant. My hashing needs are typically focused on strings shorter than 100-something chars, Int32 references, or Int64 references, typically varying from a few hundred to less than twenty thousand elements.

Food for @Daniel

Which applies to the TDictionary hashing, I see. Thank you, @Kas Ob. It is entirely possible that my prime size cargo cult stems from this article https://web.archive.org/web/20080515141600/http://www.concentric.net/~Ttwang/tech/primehash.htm which is a different algorithm than the Delphi one.

I opened the file as a binary file in a hex viewer and there were no FF or FE bytes.

I didn't make a claim. I asked a question. You answered. I asked if there was a mathematical proof that supported your answer. The other thread I mentioned seems to indicate that prime sizes have a purpose, so I'd like to understand. This is off topic for this thread, so please respond in the other thread or in DM.

@Kas Ob. It was a direct cut/paste from BDS to the forum editor in Chrome - so hard to say where the $FEFF was introduced. I can't replicate that error using BDS or VSCode. A proper realtime OS with a functional nanosleep is a better choice than windows for high resolution timing, I suppose.

Is there mathematical proof for that?

Anyways - under Windows, we have the so-called multimedia timer, https://docs.microsoft.com/en-us/windows/win32/multimedia/about-multimedia-timers but a caveat is that actual minimum resolution varies with platform and device https://docs.microsoft.com/en-us/windows/win32/multimedia/timer-resolution var TCaps: TTimeCaps; // WinAPI.MMSystem; rc: MMResult; begin rc := timeGetDevCaps(@TCaps, SizeOf(TCaps)); // WinAPI.MMSystem; if rc = 0 then Writeln(Format('Min %d / Max %d', [TCaps.wPeriodMin, TCaps.wPeriodMax])) else Writeln(Format('timeGetDevCaps returned %d', [rc])); end; outputs Min 1 / Max 1000000 on my computer. Oddly enough, the resolution is 1ms - so, in theory it is impossible to use a timer to get a better resolution than 1 ms. Still - the WaitableTimer has 100ns resolution, so that should work, right? https://docs.microsoft.com/en-gb/windows/win32/api/synchapi/nf-synchapi-setwaitabletimer function NanoSleep(const NanoSec: Int64):Boolean; var Timer: THandle; Constraint: _Large_Integer; begin Result := False; Timer := CreateWaitableTimer(nil, True, nil); if timer <> 0 then try Constraint.QuadPart := -NanoSec; if SetWaitableTimer(Timer, Constraint.QuadPart, 0, nil, nil, False) then begin WaitForSingleObject(Timer, INFINITE); Result := True; end; finally CloseHandle(Timer); end; end; but even that is incredibly erratic. const ns: Int64 = 10000; var st: TStopWatch; ix: Integer; begin st := TStopWatch.StartNew; for ix := 1 to 10 do NanoSleep(ns); st.Stop; Writeln(st.ElapsedMilliseconds); end; and does not seem to work at low intervals - unless I screwed something up? Windows is not a real time OS - so it seems milliscond timing will be iffy - unless you use a power consuming loop of instructions - and that is not desirable.

I am curious - when would you need such minuscule intervals?

TRttiType.GetProperties.GetAttributes vs TRttiType.GetFields.GetAttributes Personally, I've avoided setting props on fields and only set them on properties. There are parts of the RTL where the opposite applies - f.x. for REST.JsonReflect, which checks the fields and not the properties.

Guilty. Like OOP, Generics are sooo addictive!

My first thought was - why not use a thread with sleep if you need that fast a timer - but - again, multithreading raises its own issues.

What about the theory that dictionaries have fewer collisions if you set the capacity to be a prime number ? Fact or fiction? Personally, I do actually set the capacity to a prime, but I am not quite sure if it because it is sound advice or if it is a cargo cult thing. Edit: Funny enough, @Tommi Prami posted an alternative approach.

Less readable code can be greatly alleviated with decent commentary. Document general intent and method rather than say what each line does.

Empirically proven to work. "Awful" can be - slow code, albeit in a context where performance is not required - cryptic code - code that could be simplified with modern RTL code Anyways - Refactor when you need to, and not just because you'd like to - unless unlike most devs, you have time to spare. Oh - as @Stefan Glienkesuggests: Make sure you have the tests to validate your refactoring.

Another challenge is knowing when NOT to refactor. "This code works, but it looks awful... should I refactor?"

Since threading is non-trivial, it is hard to make examples that are not either non-trivial or oversimplified. You may find yourself writing quite a bit of scaffolding code, which would have come for free with OTL.

What are your needs / goals?

Is the behavior erratic across multiple executions of the same application - or is it specific applications that do not let you capture?

True, but the point is a more natural limit of variable scope. var ref := Some.Array[Index1].Reference; var thing := Function(Index1).Thing; if ref.Value <> thing.Value then begin ... end; // ref and thing ARE present here I guess you could wrap it in another pair of begin/end - but that would look a bit strange, while the with signals clearly that these are local.

I'd like this to be possible, and a compiler switch that bans the old with statements. with var ref := Some.Array[Index1].Reference, var thing := Function(Index1).Thing do begin if ref.Value <> thing.Value then begin ... end; end; // ref and thing are not present

Did you mean https://quality.embarcadero.com/browse/RSP-18953 - Tommi? 21814 is the Windows 10 Ansi/UTF-8 QP - which, by the way, returns different values on my Windows 10 Enterprise 1809 10.0.17763.831, depending on which PowerShell version you use. PowerShell 5.1 IsSingleByte : True BodyName : iso-8859-1 EncodingName : Western European (Windows) HeaderName : Windows-1252 WebName : Windows-1252 WindowsCodePage : 1252 IsBrowserDisplay : True IsBrowserSave : True IsMailNewsDisplay : True IsMailNewsSave : True EncoderFallback : System.Text.InternalEncoderBestFitFallback DecoderFallback : System.Text.InternalDecoderBestFitFallback IsReadOnly : True CodePage : 1252 PowerShell 6.2.4 Preamble : BodyName : utf-8 EncodingName : Unicode (UTF-8) HeaderName : utf-8 WebName : utf-8 WindowsCodePage : 1200 IsBrowserDisplay : True IsBrowserSave : True IsMailNewsDisplay : True IsMailNewsSave : True IsSingleByte : False EncoderFallback : System.Text.EncoderReplacementFallback DecoderFallback : System.Text.DecoderReplacementFallback IsReadOnly : True CodePage : 65001

What are the odds that FMX in Rio uses something that is not present in SdkVersion 14?

In that case, Remote Desktop Manager is the way to go.