Tommi Prami

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.

I'll check those later. Thanks. -Tee-

That is not complete story tough. Production APP about : 128641ms Running test: "Reference" (RELEASE build) Run count: 5 Min: 113,458ms, Average: 118,925ms, Max: 127,638ms Running test: "Reference" (DEBUG build) Run count: 5 Min: 13489,222ms, Average: 13957,058ms, Max: 14276,866ms While debug mode is slow, but not even close as slow what I experienced when that piece of code is part of the whole program (Not isolated small piece of code in separate ap). Because it took minutes to complete. (Yes I measured it). What in earth could cause that. Memory alignment? Somehow the bitmap is differently in memory (bad alignment etc?). One obvious could be Compiler options, have to check those later. -Tee-

Thanks for all info, suggestions and mainly sceptics so far 🙂 -Tee-

Intermediate info: It is way faster than I thought. I got bit (very badly) by FastMM4 full debug mode. It takes ages to do that memory allocation Scanline does. So there is room for optimizing the extra scanlines out, and maybe some other stuff also. So not too much user preservable room for optimization there is it first seems. Still can make it faster tough. I have some kind of test project cooking, trying to check how far I can push it. I'll publish it later if I got something out of it.

Hmm, I think this is lost in translation or something like that. Process is and willöbe 100% same, I am not asking help to change process, just optimize what there already is. As far as I know it can't be even changed changed. I am just looking a way to optimize it. Have received valuable info, so I thank all for that. Method input is TBitmap with 32bit "pixel format" and pixels in it has to be saved into stream with 3bytes per pixel in order of RGB. Sorry if I am not clear enough.

Like I said earlier, part of 3rd party library/Component and can't be changed. -Tee-

I think this is pretty clear in the Caption or I at least think it is pretty self explanatory. Stream of bytes in order of RGB. What happens after this is another story all together.

Should always study the code one is calling 🙂 I've always thought that it would just return pointer to the data and offset that. depending the line you access. Good to learn new things.

Yes, it is saved to file...

Not huge, but large, but this is for 7x3cm logo on the print so overkill for that. But that makes this piece of code even worse 🙂

Thanks, I'll have a look...