Tommi Prami

You got good Delphi implementation of that 😄

OK, Let me try again, any reasonably fast, Free and OpenSource implementation of good Random number generator algorithm, that is tested statistically to give better randomness than Stock RTL one.. I have no knowledge on which algorithm is best for what, that is why I am asking. I have an impression that Mersenne twisters are not suggested anymore. As mentioned above xoshiro / xoroshiro generators I have heard are good. But again, have no idea how to choose better one. I would not ask if I had all needed info 🙂 -Tee-

I just need random numbers that have better quality than stock Random() function in the RTL. I think that is valid requirement. -Tee-

For now, I am open to all suggestions 🙂 Just need to get random numbers and have some Randomize-functionality. As long it is way better tna build in RTL version. If can use it to replace RTL version in code, way or other, I am happy 🙂 -Tee-

Sometimes removing withs, especially nested ones, are really tricky. Easy to mess up. Just got bit by this other day. IDE/Compiler/LSP must know which is which, so it would get first pass way faster than doing it manually. https://quality.embarcadero.com/browse/RSP-18953?filter=-2 On a side note thee has not been too much love towards refactoring features in IDE. Hope it would get more and ones we have to get better. -Tee-

Exactly. And also removing withs are quite pain by hand. More complicated it is. Nested with clauses are pure evil. Even ones that seems trivial are pain to remove sometimes. -Tee-

Hello, Is there a way to tell TDataset that now would be preferred time to do some filtering of records? Current record or all. -Tee-

That is discussion of another time,. That code Above was satisfactory for my needs. But maybe helpful for some other tough. Or different use case. Thanks for your suggestion. -Tee-

Sure that works, but I think that filters whole dataset, which I did not want. -Tee-

I do not present the problem at there. That was my Quick and dirty solution to the problem -.Tee.-

Hmmm... No wonder... 🙂 Dataset have emails, I load filtered emails on startup to the TSringList. Andf use OnFilerRecord (Etc event of dataset to filter those out). I need also to filtr out rows from dataset on runtime, and I need to kick the TDataset that Hey Dude, Filter current work right now. And code above more than less filled my need. Using GotoBookMark(). -Tee-

Problem was that I Have filtered dataset, but the Filtering criteria or filtered rows criteria is changed separate from data on dataset.. I have something like: function KickDatasetFilterRecord(const ADataSet: TDataSet): TBookmark; var LBookmark: TBookmark; begin LBookmark := ADataSet.GetBookmark; try if not ADataSet.Eof then ADataSet.Next else ADataSet.Prior; Result := ADataSet.GetBookmark; finally if ADataSet.BookmarkValid(LBookmark) then ADataSet.GotoBookmark(LBookmark); end; end; procedure Foo(const AEmail: string); begin FFilteredEmails.Add(AEmail) ; // Filter current wor now. Dataset.GotoBookmark(KickDatasetFilterRecord(Dataset)); end;

One way seems to use GotoBookmark.

Hello, One piece of code we use (3rd party component) is taking bitmapdata and put rgb values to stream. And on large bitmap this will take quite a long time, due the sheer amount of pixels to go through, Original code was even sl,owe because it used Pixels []-property. Now it uses Scanline. There is two different buffering (now) strategies but changes to that buffering (Collect data to byte array and write that once and awhile to stream) strategy changes can only go so far. I was just pondering coulöd there be any weird bit fiddling trics etc to get that RGBA -> RGB byte triplet faster? That is the most common operation anyhow. I eman this: LLine := ASrcmap.Scanline[LY]; for LX := 0 to xdim - 1 do begin bbuff[BP] := LLine[LX].R; // RGBColor^.red; bbuff[BP + 1] := LLine[LX].G; // RGBColor^.green; bbuff[BP + 2] := LLine[LX].B; // RGBColor^.blue; Inc(BP, 3); end; Any ideas?

Added "BitShifter and write 3 bytes at the time" to buffer code provided by @Anders Melander I would have guessed that this would have speeded things up a bit. But no 😄 -Tee-

Some claim it is rebranded SynEdit, which it is not. Author said right away that Show me where there is SynEdit code, and I'll change it. No one presented anything (Meaningful at least) TBCEditor works fundamentally differently (Or made differently) than SynEdit.

TBCEditor was made by my coworker. Saying "violation the SynEdit license" might be bit overstatement, as I remembered someone found couple of trivial pieces, when Author said show me the code and I'll rewrite, nobody did nothing so... It was ground up rewrite more than less from Scratch. Spend couple of years coding it every day basically. This weird dude who ripped TBCEditor off was extremely rude, so Author just took it off of public. Editor (or it's descendant) is in Text Editor Pro, which is very good text editor tool. And yes, totally abandoned and left in state that would need lot of work from dedicated people to fix for sure.

This seems interesting Random number generator algorithm, don't have any authority to actually prove it tough. https://www.pcg-random.org/ There is some Delphi implementation at https://github.com/LUXOPHIA/LUX IT is way too complex if you only need one algorithm. Also one 32 bit version at https://github.com/mpodvin/PCG32-Random. Dunno how it is going to compare with https://bitbucket.org/egrange/dwscript/src/master/Source/dwsRandom.pas if someone knows, I would be happy to learn. -Tee-

Problem (to me) is that I've seen 10x speedup without using that much ScanLine, And would be nice to abple to reproduce that scenario. Some one also made simple test app and saw that ScanLines too significant time, alone, without other code.

Fair point. Said in some point that this is 3rd part library, very small part of it, tough more than less obsolete and we started to fix it our self's, But some portion we have no control of it, like TBitmap (Would be total rewrite of huge library)

1, not my code originally so, preserve original code, but noted, did not know that type existed 2. Can be changed then, did not realize that 3. Jpeg unit I think can be removed then. Have to look at that I thought "32bit RGBA TBitmap to RGB byte stream." as caption is pretty obvious that data is in the TBitmap originally. In this case bitmap is loaded from several sources, from DB and some is made in Code etc. But not from file as such. Made couple changes of your observations

Small Test APP, https://github.com/mWaltari/ImageStreamTest This DOES NOT reproduce the ultimate slowdown I saw in the out App. This is way faster. In production app, redusing the ScanLine calls made it at least 10x faster. But if you just want to check this out, there you are... -Tee-

Because RTL and VCL code is build also with inlining I think, so it was valid thing to test I think. No, milliseconds. LResultArray := LStopWatch.Elapsed.TotalMilliseconds; Number format is standard Finnish, which can be misleading to some, decimal separator is comma, and thousand separator is "space". Will do that when I've got time for that. Also publish my test code so anyone can check it if want to. Big problem here is that profiling is that I can't still reproduce the level of slowdown in production App. And is very hard to profile without instrumenting one (which I don't have) without loosing all to the noise, of all other processes in the app. What I know that main problem is the ScanLine, but Dunno why it is sometimes very fast and takes ages in our production code (vs in test app). It is at least 10 times difference. I've tested production code with just one Scanline and inc the pointer to next line, it'll at least 10x faster as I stated before. Just have to reproduce that in the test App. This, sadly, will be kind of marathon can't spend to much time on this currently. But I'll get there 🙂 -tee-

Put also Inlining control to Off in the test app, still about as fast as before: Running test: "Reference" (DEBUG build) Run count: 5 Min: 12459,948ms, Average: 13538,720ms, Max: 14904,923ms

Use same FastMM in test app with same settings than in production app. And also the overflow and range checking did not produce as slow situation than in the production app case. This is Overflow and Range checking on. Running test: "Reference" (DEBUG build) Run count: 5 Min: 12707,820ms, Average: 13247,058ms, Max: 14194,733ms Production case also has somewhat smaller bitmap also than in the test app. this is getting weirder. And the production app case is way way slower than in this test app. Only thing currently) I can think of is that Production bitmap addresses go Bottom Up and in test Appm Top to bottom. Just have to figure out how to get that situation tested.