Leaderboard

Now includes Delphi / RAD Studio options. I encourage you to take the survey! https://www.ideasawakened.com/post/make-your-voice-heard-2022-stack-overflow-developer-survey-includes-delphi

Make a cool demo using Skia4Delphi and Delphi 11.1 Alexandria, post it on GitHub, be the envy of all your friends, and maybe win a new M1 Mac Mini! Visit the official contest page: Skia4Delphi GUI Beauty Contest See also the latest Skia4Delphi webinar: Supercharge Your User Interface with Skia4Delphi - Webinar Replay - YouTube

Kinda hard to do proper multi-branch management from within the Delphi IDE.

My knowledge of processor architecture is insufficient to answer this question. The work packages are advanced records in a dynamic array, so their data is located within the same memory area on the heap. Which turned out to be the problem. The work memory area of each work package was declared like this: TWorkPackage = record FCounter: PInt32; FIsDone: LongBool; FScanLine0: PByte; FBytesPerLine: Integer; FWidth: Integer; FHeight: Integer; FTop: Integer; FBottom: Integer; FPixelValues: TMedianValuesArr; FMedianPixelArr: TMedianPixelArr; FArr: TBrightnessMatrix; FSum: int64; FStopwatch: TStopwatch; end; And these were stored in a dynamic array, so they were all located within the same memory area. FMedianPixelArr is constantly being written to in all threads. If I understand the cache line stuff correctly, the fact that these records were stored all within a memory block smaller than the CPU cache line (apparently 256 Bytes at most with current CPUs) this caused the cache becoming invalid for all threads every time one of the threads wrote to this area. For testing this, I have now simply increased the size of the record by 256 bytes by adding an array [0..255] of byte to it so each of them is larger than the maximum possible cache line. Here is the timing after this change: 1 calls using 1 threads: 1143 ms (TotalTime [ms]: 1125 SingleTimes [ms]: 1125) 1 calls using 2 threads: 607 ms (TotalTime [ms]: 1124 SingleTimes [ms]: 565 559) 1 calls using 3 threads: 451 ms (TotalTime [ms]: 1186 SingleTimes [ms]: 395 393 398) 1 calls using 4 threads: 368 ms (TotalTime [ms]: 1222 SingleTimes [ms]: 308 298 312 304) 1 calls using 5 threads: 367 ms (TotalTime [ms]: 1357 SingleTimes [ms]: 244 306 303 242 262) 1 calls using 6 threads: 344 ms (TotalTime [ms]: 1533 SingleTimes [ms]: 228 259 274 271 245 256) 1 calls using 7 threads: 296 ms (TotalTime [ms]: 1636 SingleTimes [ms]: 222 246 227 219 236 250 236) 1 calls using 8 threads: 304 ms (TotalTime [ms]: 1806 SingleTimes [ms]: 226 222 224 225 227 225 224 233) 1 calls using 9 threads: 322 ms (TotalTime [ms]: 1909 SingleTimes [ms]: 230 226 198 238 220 197 199 195 206) 1 calls using 10 threads: 326 ms (TotalTime [ms]: 2009 SingleTimes [ms]: 174 216 172 208 176 236 232 178 213 204) 1 calls using 11 threads: 295 ms (TotalTime [ms]: 2140 SingleTimes [ms]: 232 222 221 165 221 171 201 162 158 181 206) 1 calls using 12 threads: 273 ms (TotalTime [ms]: 2494 SingleTimes [ms]: 212 208 224 210 227 210 212 212 198 202 198 Which is exactly what I would have expected: The total processing time is reduced roughly inverse proportionally with the number of threads until the overhead of splitting the work reduces the potential gain of using more threads. Hm, looking at the single times values: Given that with each additional thread the number of lines each thread needs to be processing decreases, I wonder why these times don't get any lower than around 200 ms. Anyway, thanks @Anders Melander you seem to have nailed the problem.

Why would you try to put these two together. You use TortoiseGit inside explorer surely.

@dummzeuch I can confirm that this issue is resolved with the latest source and I can now perform case-insensitive searches with regular expressions.

Ah the drop bears, those are reserved for hot Swedish tourists -