Leaderboard

I have uploaded a new development snapshot for the (upcoming) IDE Fix Pack 6.5 IDE Fix Pack Snapshot Download What's new: Added: (IDE) Fix for RSP-23006: Edit controls in the ObjectInspector aren't clipped by the scrollbar anymore (10.3+) Added: (IDE) The compile progress dialog is updated only every 80 ms now. And if a remote desktop session is detected it is only updated every 250 ms. The IDE compiler runs in the main thread, so every GUI update affects the compilation time. Added: -x--jdbg compiler option extension that creates and attaches a jdbg-file. You don't need a detailed map file (-GD) anymore to create or attach a jdbg-file for the binary file. Attaching the jdbg PE section is done after the linker closed the binary file. -x--jdbg and -x--jdbg=1 create a jdbg-file -x--jdbg=2 attaches the jdbg data to the executable/dll/bpl. Question: "Why is the jdbg file smaller than my old file?" - Answer: "The old file was created with an older version of JclDebug.pas." Added: -x--unitstats compiler option extension outputs unit filenames for units with "unitname in 'filename'" entries. Added: -x-fvs compiler option extension also generates faster interface call stubs for virtual methods that are final or in a sealed class. Added: Package compilation is a lot faster in the linker and cleanup phase. Added: Faster ObjectTextToBinary (DFM) implementation by removing unnecessary string comparisons. This improves the linker's performance when it converts DFMs to resources. Added: Faster map file creation by using a much faster Sort-By-Address implementation and a faster \n to \r\n converter. Added: Faster unitname to unit filename resolving (unitname in 'filename') The compiler used a Byte as hash-value and a single linked list. The code is now replaced by a hash-map with a 32 bit hash-value. Added: Faster compiler inline handling for projects with lots of units. Added: The command line compiler uses a double linked unit list to remove and reorder items faster. The IDE compiler still uses the original single linked list because some other code in the IDE does something with it and I couldn't make it not crash. Added: LoadString cache for compiler error/warning/hint messages. The compiler loads the warning/hint string and then decides not to show it. The cache prevents the compiler from calling LoadString too often. Added: Some PAnsiChar/PWideChar RTL optimizations for the IDE and IDE Fix Pack. Fixed: Compiler option extensions didn't work in dcc*.cfg and project.cfg files. Now you can specify -x-* options also in *.cfg files. Fixed: Don't crash if a 3rdParty tool destroys the Castalia Clipboard Form. Fixed: -x-cgo compiler option extension crashed the 10.3 compiler. Removed: The "Exception catcher" patch for ErrorInsight is no more. It didn't have any functionality.

I have finally found solution and posted it here: https://stackoverflow.com/a/61874765/3225668

So if I am the Primary Contact (as I paid the bill myself) I still have to assign myself somewhere as an Authorized Contact? Damn, the Embarcadero's sales model does not change with years, they are targeting businesses, not developers. And don't remind me about all this reseller-only distribution and obligatory quote request for updates ☠️...

You are right: FastMM5 challenged me... and since no one responded to my offer about helping it run on FPC/Linux, and also since I wanted something Open Source but not so restrictive, I created https://github.com/synopse/mORMot2/blob/master/src/core/mormot.core.fpcx64mm.pas which is GPL/LGPL and MPL. So you can use it with closed software. It uses the same core algorithms than FastMM4. I like it so much, and missed it so much in FPC... 🙂 I was involved in ScaleMM2, and a per-thread arena for small blocks didn't convince me: it tends to consume too much RAM when you have a lot of threads in your process. Note that a threadvar is what the FPC standard MM uses. I wanted to take the best of FastMM4 (which is very proven, stable and efficient), but drive it a little further in terms of multi-threading and code quality. FastMM4 asm is 32-bit oriented, its x86_64 version was sometimes not very optimized for this target - just see its abuse of globals, not knowledge of micro-op fusion or CPU cache lines and locks, and sparse use of registers. Also focusing on a single compiler and a single CPU, with not all the features of FastMM4 in pascal mode, helped fpcx64mm appear in two days only. Last but not least, I spent a lot of time this last year in x86_64 assembly, so I know which patterns are expected to be faster. The huge regression test suite of mORMot helps having a proven benchmark - much more aggressive and realistic than microbenchmarks (like string concatenation in threads, or even the FastCode benchmark) on which most other MM relies for measurement. When the regression tests are more than twice faster than with the FPC standard MM on Linux - as @ttomas reported - then we are talking. It runs a lot of different scenarios, with more than 43,000,000 individual tests, and several kind of HTTP/TCP servers on the loopback, running in-memory or SQLite databases, processing JSON everywhere, with multiple client threads stressing it. When I run the test on my Linux machine, I have only a few (less than a dozen) system Linux nanosleeps (better than Windows sleep) , and less than 2 ms waiting during a 1 minute of heavy tests - and only for Freemem. I really don't like the microbenchmarks used for testing MM. Like the one published in this forum. For instance IntelTBB is very fast for such benchmarks, but it doesn't release its memory as it should, and it is unusable in practice. I guess that some user code, not written with performance in mind, and e.g. abusing of str := str+'something' patterns would also be more than twice faster. And if your code has to reallocate huge buffers (>256KB) in a loop, using mremap on Linux may make a huge performance boost since no data would be copied at all - Linux mremap() is much better than what Windows or BSD offer! Yes, huge memory blocks are resized by the Linux Kernel by reaffecting its TLB redirection tables, without copying any memory. No need to use AVX512 if you don't copy anything! And plain SSE2 (with non-volatile mov for big buffers) is good enough to saturate the HW memory bandwidth - and faster than ERMS in practice. IMHO there was no need to change the data structures like FastMM5 did - I just tuned/fixed most of its predecessor FastMM4 asm, reserved some additional slots for the smaller blocks (<=80 bytes are now triplets), implemented a safe and efficient spinning, implement some internal instrumentation to catch multi-threading bottlenecks, and then Getmem didn't suffer from contention any more! I knew than FastMM4 plus some tweaks could be faster than anything else - perhaps even FastMM5.

That is not the reason. Your test functions may simply be holding a hidden local reference to the IItem that you create and add to the list, so the item is not fully released until after the list has been freed first. Try this instead to isolate that reference so it gets released sooner: procedure TestDestroyOnly; var List: TItemList; procedure AddItem; begin List.Add(TItem.Create as IItem); end; begin Writeln( 'Start Test - Destroy Only'); List := TItemList.Create; try AddItem; finally List.Free; end; Writeln( 'End Test - Destroy Only'); end; procedure TestWithExplicitClear; var List: TItemList; procedure AddItem; begin List.Add(TItem.Create as IItem); end; begin Writeln( 'Start Test - Explicit Clear'); List := TItemList.Create; try AddItem; List.Clear; finally List.Free; end; Writeln( 'End Test - Explicit Clear'); end;

Getting notification isn't really what concerns you. You know how to do that. What you need to be able to do is block shutdown until you have finished saving any data. The way that is handled changed in Vista. The documentation you need starts here: https://docs.microsoft.com/en-us/windows/win32/shutdown/system-shutdown

Yes. You are right. As I read it .NOFRAME tells the compiler that I'm not calling anything and don't need a stack frame. Of course that means I'm relying on the existing stack frame having room for the single register we're pushing. I guess removing .NOFRAME would be the safe thing to do.

SETZ BL XOR EAX, EAX MOV AL,BL Don't you just need SETZ AL MOVZX EAX, AL Also, .NOFRAME is wrong here. You need the frame to preserve RBX. At least that's how I understand it.

I submitted a QP report for InterlockedCompareExchange128 not restoring rbx

My employer gets the bills, we developers get the invites - but it wasn't always like this. We pestered our local sales rep to fix it.

This is the point that I've been making all along.

Processes and Application Lifecycle Understand the Activity Lifecycle Android is the same way. Background apps have to let the OS know that they are still "running" and should not be killed off. The OS is still free to kill them if it NEEDS to, though (low resources, etc).

You are right about permission part. "Sorry, I can't say anything, because of RadStudio Beta NDA will kill me and eat my soul" is still valid for everything else.

Added a quick blog post on inline variables: https://www.ideasawakened.com/post/newly-discovered-hidden-benefits-of-inline-variables-in-delphi

New NG 2020.0 installer are available now! The new Next Generation (NG) Control Suite supplements the LMD line of products for Embarcadero Delphi/C++Builder. While LMD VCL products still support legacy IDEs (Delphi/C++Builder 6 and higher), NG components make use of new IDE and language features of most recent IDE releases (Delphi/C++Builder 2009 and above). NG Controls are designed to be lightweight and task-focused. They do not represent a complete framework like the LMD VCL platform and can be used at the same time with LMD VCL controls, the VCL or any other 3rd Party toolbox. NG Complete contains all features of the following NG standalone products: NG ConnectionPack (Delphi XE and better) NG DialogPack (Delphi 2010 and better) NG Drag&DropPack (Delphi 2010 and better) NG HTMLPack NG SerializerPack (Delphi XE and better) NG ValidatorPack Major changes cover vastly updated ConnectionPack which supports new obligatory Google authorization schemes. Please check the updated ConnectionPack documentation. Summary of changes in the NG 2020 platform release can be found on NG What’s new page. Check the new trials and compiled Exe-Demos (now digitally signed) athttps://www.lmd.de/downloads/#ng-complete-2020 If you are interested in purchasing check out the order Page:http://www.lmd.de/shopping  If any questions are left, please contact us at mail@lmdsupport.com!