Tommi Prami

Voted If possible edit the code parts (I think there is way to have prettied code in Jira) so the bug report would be essier to read.

Innosetup has LZMA and LZMA2 code, might be that it is using it "in own way", did not check that closely. But there are .obj files for 32 & 64bit build and so on. Don't know is the headers translated fully. Ah did not see that this was Cross platform, and those might not be portable, but anyhow, maybe someone else can use the info,..,. -Tee-

Download link gives 404

I could not find simple summary on features what are available. Would help. -Tee-

Yo, As windows does the similar thing when doing file operations in explorer, if it start to take time, then it bring s dialog up, and do not flash it if operation is fast (At least sometimes it seems this way). I've been pondering this kind of pattern for a long time. Never tried to code this, but as concept it might be nice, but I have feeling that this is easy to mess up, and for sure easy to kiss some corner cases to have super weird issues, I think. My idea would be something like LLazyProgress := LAzyProgressFactory(ParentFormEtc, lpMarquee, 300); try ... Work finally LLazyProgress.Free; end; If this would be network or file operation, sometimes it might be fast and sometimes very very slow,. And you kind of can't know for sure., My idea was that there would be some, like 300ms delay, if process takes more time than that, progress dialog would show, It could be marquee style, or if progress is more defined and known, could pass some callback for the actual progress and show it, Any thoughts/ideas on this. Mainly if problem with fluctuation of time process takes, sometimes there would be fast flash of dialog for user, and they never could see what was it. Completely different discussion should there be some kind of UI element to show user that progress has finished. -Tee-

Relocating actual work to thread, is what I would like to avoid, as it adds quite log extra complexity, like needs new connection to database etc. This why I asked because there might not be good solution without having actual work in a separate thread/task (= thread). For sure having the actual work in separate thread would have its own benefits, like they would crash if they mess around with GUI, but most likely work in legacy app has some GUI updates, that's why it would make it much easier to just keep the work in main thread. So far what I've been pondering that it would need thread, but been thinking that maybe the Lazy progress bar showing logic would be in thread. I thought something like this could work: 1. Have and initialize background thread which waits for progress bar dialog requests. 2. Also create initialize progress bar dialog 3. Request progress bar 3a If progress bar request is still alive and time period is over, show dialog 4. when work is done, ask thread to hide the dialog, if visible at all 5. free the request Needs some thread safety and TEvents or something for signaling and so on. Also Progress bar dialog would naturally be modal, and process messages in a way or other.

I most likely would have more than less both, but slightly off topic...

I tried to read the articles linked, and it was not very clear will this affect we signing our apps, or is this just when it is done in Azure or so. And where actually requirement is coming from, what actually will enforce this for us, if will. MEaning how resulted signed app will differ from what we have now? Articles , to me, are written in way that you need lot of background information to actually understand what this all means. -Tee-

https://quality.embarcadero.com/browse/RSP-39546?filter=18027 Vote and/or collaborate if feels serious to you... -Tee-

Even tough this is very weird example, but seems like something that with some bad luck one could get hit by that. -Tee-

Please report to the Bug Report that you could reproduce it...

RTL has Buffered file stream now, but I think there is no buffered Memory stream, I think. is there fast implementation available? I made long long time ago one, but that was not super good implementation and don't have code anymore. At least then it made some code way faster, and Stringbuilder I believe is not super fast, and and can't handle binary data 🙂 -Tee-

Not problem for me, but "interesting" choice to implement those features with helper, they kind of can modify existing classes quite freely if they want 🙂 -Tee-

To me quite the opposite, just the release we needed. Quality updates should come more frequently IMHO. -Tee-

Fellow forum members educated me of feature I did not know existed, or I knew, but I never used it this way. I've attached pdf-file for the info. Thanks all helping to get the call count, this is pretty cool. Get call count with Delphi Debugger.pdf

Now that went through TMemoryStream code, it is buffered... I must confuse it into some other stream class, sorry about that. But really interested how to get call count of the non breaking breakpoint tough...

That would be good to investigate, how I can see the count like that, never knew you could setup a breakpoint like that, so how to do that?? Non braking breakpoint yes, but how to see how many times it is called... Also should run as release build with optimizations on, to see how it runs then. (This was pretty much similar, little bit slower, but OK)

I do fast and crude test. Good that I did, speed gain is nice, prosentually, but it is much faster that I though: procedure TForm3.Button1Click(Sender: TObject); const LOOP_MAX: Integer = 90000000; DATA: RawByteString = '0123456789'; var LStopWatch: TStopWatch; I: Integer; LStream: TMemoryStream; LDataLength: Integer; begin LDataLength := Length(DATA); LStream := TMemoryStream.Create; LStopWatch := TStopWatch.StartNew; try LStopWatch := TStopWatch.StartNew; for I := 1 to LOOP_MAX do LStream.Write(DATA[1], LDataLength); LStopWatch.Stop; finally LStream.Free; end; Memo1.Lines.Add('No preallocation: ' + FormatFloat('0.000s', LStopWatch.Elapsed.TotalSeconds)); LStream := TMemoryStream.Create; LStream.Size := (LOOP_MAX * LDataLength) + 1000; LStopWatch := TStopWatch.StartNew; try LStopWatch := TStopWatch.StartNew; for I := 1 to LOOP_MAX do LStream.Write(DATA[1], LDataLength); LStopWatch.Stop; finally LStream.Free; end; Memo1.Lines.Add('Preallocation: ' + FormatFloat('0.000s', LStopWatch.Elapsed.TotalSeconds)); end; No preallocation: 1,150s Preallocation: 0,647s Nice speedup, prosentually, but time saved in real world situation is very small. So no point of optimizing this, in my current case. This way. Maybe my mary failed me, and my original optimizations where pre FastMM times. or I just looked how many percent faster it was 😉 Or both.... -Tee-

For sure. My experience is that if you write lot of stuff to to stream, and if there is lot of reallocation, it'll be quite slow. Need to measure this for sure, before commit into anything. All I know i've used buffered stream to speed up very close to same situation now. I just remember that some parts of the code got way faster, and overall saw significant speedup. I think this comes down to how much data is written and how small pieces and so on, in other words, how many reallocations will happen in real world. I think I logged the final stream sizes for a day (it was an server which made Xml files) and used Stetson-Harris method to pic some nice size for initial allocation size, and adjusted growth strategy to get some kind of balance and not to allocate way too large buffers. Concatenating strings on FastMM is fast, but still I managed to make nice speedup back then. It is quite easy to make Buffered stream, but testing and handling all possible corner cases you first miss... That is why I am asking if there is good implementation that I could test, does it make sense or not (in this case) 🙂 -Tee-

Reallocation for sure.

Hello, QP here: https://quality.embarcadero.com/browse/RSP-38978 If you care, vote and or comment. -Tee-

That sounds smart implementation, if blocks are big enough, SaveToFile etc (combining the data to one, or reading it to elsewhere) should be pretty fast also.

As far as I know TMemoryStream does not buffer, at least in a way that I want to use it. -Tee-

Current code writes stuff into the memory stream in small chunks, it would be _easy_ optimization to have buffered memory stream. I used to have very crude memory stream that allocated memory with some mechanism that I can't remember, it was mainly used to write XML data back then, but it made some code 20x faster. (if I recall), but some isolated cases where way faster, than reallocating all the time. One thing I remeber is that implementation did reallocate always when buffer got full, so was not super smart, just some simple growth scheme. Sure I could rewrite the code at first place, but sometimes it is legacy code of some third party library, so rewriting might be too big of a task. Would be better to get some maintained library instead, if available. But it always is case by case call which way to go. -Tee-

Sweet, could you publish code to QP as a starting point, and/or report your findings there? -Tee-