dummzeuch

I've got something called msbuildfilter as part of my buildtools, But It solves a different problem even though it does parse the msbuild output. It's not open source and I can't easily make it. So it's not possible to simply adapt it to this purpose So, no, nothing readily available up my sleeve. 😉

I have got two programs which execute the same code as the first step in some processing. It's about checking huge (like in 100 gigabytes) files for consistency. These files are basically a container for large binary data (blob) of different sizes. Each blob has some small metadata (a few 100 bytes) stored just in front of it. The data is stored in chunks of n blobs each chunk is preceded by a descriptor which contains a pointer to the next descriptor and n pointers and size of blobs stored in this chunk. The structure is like this: file header chunkA descriptorA data1 metadata1 blob1 data2 metadata2 blob2 data3 metadata3 blob3 ... dataN metadataN blobN chunkB descriptorB dataN+1 metadataN+1 blobN+1 dataN+2 metadataN+2 blobN+2 dataN+3 metadataN+3 blobN+3 ... data2*N metadata2*N blob2*N ... These files are created incrementally on a different computer by a different program. Every time a blob is added it gets appended to the last chunk until that chunk is full at which point a new chunk appended appended. Then these files are transferred to the computer that runs the programs I am talking about here. There they are available from a local hard drive (so there is no network access involved when reading them). Both programs read the metadata from the blobs and check them for consistency. In order to do that they first read all the descriptors and put them into an array. Then they go through these descriptors and read the corresponding metadata for each blob. This means that they read small parts from all over the huge file, skipping the actual binary content in the process. The first time this is done in Program1, it takes several minutes. When I repeat this the second time (even when exiting the program and starting it again) the full process takes only a few seconds. So I thought that Windows 10 does some really efficient caching which is great. But then I started Program2 which as the first step also does the same consistency check (same source code) on the same file. Program1 was still running but had already finished the processing. Program2 then took several minutes to complete that check. When I abort the check, close Program2 and then restart it again, the check moves to the entry it last processed within a second and then again takes much longer to process the rest. Once it's done, exiting it and starting it again the same effect happens as with Program1: The consistency check takes only seconds. To summarize: Program1 takes several minutes for the check on the first run. Program1 takes only a few seconds for the check on subsequent runs. Program2 takes several minutes for the check on the first run even though Program1 had just done the same check on the same file and was still active. When I abort Program2 and restart it again, it only takes seconds to reach the position where I aborted the last run and then slows down again. Once Program2 has finished processing the file, running it again the processing only takes seconds. Can anybody explain this phenomenon to me? If it's Windows caching I would have expected that Program2 would only take seconds because it would take advantage of the data in the file cache put there by Program1. But that doesn't happen. Just in case it matters: Both programs are Delphi 2007 programs (so 32 bit) and they are running on Windows 10 64 bit. The checking code is exactly the same in both.

That sounds as if it might be a likely explanation. Unfortunately I haven't got a 32 bit OS available to me any more (the last one was Windows XP and went out about half a year ago) and I can't simply port this code to 64 bits either. Maybe I can recreate the effect with some simpler code though.

No COM or OLE in sight. This is plain Delphi code, using stream IO.

I looked a the performance tab of Task Manager and saw that during the fast access (presumably from cache) no disk access was shown "Active time" was 0). During the slow access (presumably not from cache), disk access was shown ("Active time" was high). By "cache counter", do you mean the number shown at the "cached" label (it says 3.9 GB and doesn't really change much)? I can't see anything called "cache counter" there. I also tried the resource monitor but it didn't show anything enlightening. The disk is local to me. I can see it in the computer sitting below my desk, it's attached via SATA to the on board controller, and it's a single hard disk (no SSD, no RAID). There is no Server involved at all. I didn't try perfmon (somehow I forgot that it exists).

st := TdzFile.Create(_Filename); try st.AccessMode := [faRead]; st.ShareMode := [fsRead]; st.CreateDisposition := fcOpenFailIfNotExists; st.Open;

I can't really imagine writing any code > WriteLn('hello world'); without using SysUtils and Classes. And I doubt that many will go this way. Eliminating the VCL is a different matter. That's possible if the lib doesn't need a UI. But I would probably not even try that nowadays, not to just save a few megabytes.

Wouldn't the inline declaration solve this problem?

My dzlib has TFilesystem.CopyFileWithProgress in unit u_dzFileUtils. It's a wrapper around the WinAPI function CopyFileEx. I also seem to remember such a functionality in the jcl.

That's why I still think the old object model did it right with explicit memory allocation separate from the constructor: MyInstPtr := new(TSomeObjectType, Init(Parameters, go, here)); vs. MyInst.Init(...); (I hope I remembered the syntax correctly. It has been over a decade that I used this.)

Apache or MPL are the most commonly used when you want few restrictions.

I also used to have a free account. Many years ago, it was actually useful, but when they started trying to monetize it, the quality dropped. Nowadays, when I see them in the Google search results, I don't even bother clicking on it. But since I don't have a paid account I can't really say whether they are any good. My guess would be: No.

Dream on. It would be: "There are mostly gray headed/bald Delphi developers in your area"

Yes, I could do that, and the next time I update the package group from Github, I'd have to do that all over again. My point is: There is no simple solution built into the IDE.

Click on half a million design packages and select "install". That's the most annoying part because the design packages are intermingled with the run time packages so I'd need to click on every second one.

Why not? I did.

Actually no, it doesn't.

I don't want the DCU directory of any 3rd party component/library in my IDE's library path. In my opinion it belongs into the individual project's search path, if that project uses the library. Actually, I prefer to have the source code in the projects path rather than the DCUs.

Last time I tried to submit a bug report trough Mantis, somebody told me that it was sheer luck if anybody even looked at it. That was a few years ago though.

I can top that: 6 to 10.4 (I even considered adding Delphi 5) And yes, the path variable becomes a pain in the lower back if you install many Delphi versions to the default directories. Unfortunately updates tend to revert any custom installation directories. Using additional environment variables and adding only these variables to the path also helps.

No, there is no such tool and also no API, because this expert relies on the Open Tool API of the IDE. If I remember correctly there is a tool in the JCL that allows changing properties in dfm files. (Sorry, I missed the original post.)

Some configuration settings will only be saved when exiting the IDE, so they will always reflect those of the IDE instance you closed last. This also applies to some IDE plugins (e.g. GExperts). But apart from that there is nothing to prevent you from having multiple instances active.

GExperts is always compiled with the latest update of any of the supported Delphi versions. That unfortunately means that it may not work if the IDE hasn’t been updated to the latest version. E.g. The latest GExperts release will not work with Delphi 10.2, but only with Delphi 10.2.3, the latest update to Delphi 10.2. This is due to changes in the runtime packages that are not always backward compatible. Until a few years ago, this was no problem because when you bought Delphi you were automatically entitled to receive all updates for this version. E.g. if you bought Delphi 2007 you could download all updates for it and GExperts would simply work for you. This changed when Embarcadero tried to force all their customers to buy a maintenance subscription. Read on in the blog post.

That doesn't sound like up to date documentation.

Format is very flexible but unfortunately there is no compile time checking for the (or has it been added in newer Delphi versions?). Unfortunately it's also difficult to debug (from user error reports) since you don't see the format string in the error message. That's why I always hook this function and add the format string to the error message. If anybody is interested, I can post that unit here.