Tommi Prami

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...

Customer had bigger than 5000x3000, which is way way too big, but that just brought this piece of code into my attention..

Thanks everyone, so far. I'll have to check on this later. I'll stress that this is part of 3rd party component, which we can't totally rewrite, this process takes too much time sometimes so if we can speed up it a bit if just can. I was pondering that if I could define 4byte array and use Absolute trick to map that array to the result of method shown by the Anders above. I am still pretty much in a sleep, so all ideas I get how to implement this seems that it would have too much code in it. I bet there is elegant solution, possibly using pointers which I am not too good at. But have to try later. -Tee-

Input is as in normally in TBitmap with 32 bit pixels. TRGB32 = packed record B, G, R, A: Byte; end; and output should be stream of RGB-bytes in that order. .tee.

Would that still be 4 bytes? Right? Ah, should learn how to read first 🙂

On large bitmap this takes minutes so I am pretty sure this is the place all speedups are welcome,

One that could significantly make this faster would be to use some fast but good enough quality Algorithm to resample the image smaller first. Might be possible to do that, or not, depending how large change it would be an sure would have to be super fast resampling. But if possible with put changing the original bitmap, would be cool. -Tee-

Fast search did not give me any help for this. Is this OK place for feature requests/ bugs or is there better place? -Tee- PS. Oh, seems to be SourceForge, maybe? Which is not super nice, but It'll do if that is preferred place 🙂

Mainly because SVN doesn't support pull requequests. Make s harder to make an batch (possible but not that automated I think)

I asked this long time ago, but still can't see the point why it is better to lock down the messages. Own messages from editing. Most of the time, I at least, write message, and might come back to check it days later, if not super urgent question. and it is very annoying to see some typo or ununderstandable (is it a word) sentence. And then can't fix it. Most major Social media platforms do not disable editing , and this is only forum I've ever used which disables editing. -Tee-