Search the Community
Showing results for tags 'fastmm5'.
Found 3 results
Hello, I'm a bit confused about my code with regard to FastMM5. FastMM5 appears to be 15 percent slower than the regular in-built (FastMM?) memory manager that comes with Delphi 10.3.3. This matters, as I need to process thousands of these files, and it's been years since I've worked with Delphi. Hopefully, there's something I'm forgetting to do, and folks here can help. Here's the code: procedure TForm1.Button2Click(Sender: TObject); var StreamToReadFrom: TStreamReader; LineCounter: Integer; MyString: string; MyUnzippedStream: TBufferedFileStream; //TReadOnlyCachedFileStream<== faster than TBufferedFileStream, but still slower under FastMM5; MyStopwatch: TStopWatch; begin Memo1.Clear; LineCounter := 0; MyStopwatch := TStopwatch.Create; MyStopwatch.Start; // The file D:\variants.vcf is approximately 48.4 million bytes with 202K varying length lines of text that is not unicode MyUnZippedStream := TBufferedFileStream.Create('D:\variants.vcf', fmOpenRead); try StreamToReadFrom := TStreamReader.Create(MyUnZippedStream, False); try StreamToReadFrom.Rewind; while not StreamToReadFrom.EndOfStream do begin MyString := StreamToReadFrom.ReadLine; if AnsiStartsStr( '#C', MyString ) then Memo1.Lines.Add( MyString ); Inc(LineCounter); end; finally StreamToReadFrom.Free; end; finally MyUnZippedStream.Free; MyStopwatch.Stop; end; Memo1.Lines.Add( 'Lines read: ' + LineCounter.ToString ); Memo1.Lines.Add( 'Milliseconds: ' + mystopwatch.ElapsedMilliseconds.ToString ); end; This code is a highly simplified portion of a stage used in a complicated pipeline. This is fairly fast as it is in just one thread, but a 15% slowdown under FastMM5 for thousands of these files is not really something I was looking to see.
Günther Schoch posted a topic in Delphi Third-Party
Newly released FastMM5: https://github.com/pleriche/FastMM5 FastMM is a fast replacement memory manager for Embarcadero Delphi applications that scales well across multiple threads and CPU cores, is not prone to memory fragmentation, and supports shared memory without the use of external .DLL files. Version 5 is a complete rewrite of FastMM. It is designed from the ground up to simultaneously keep the strengths and address the shortcomings of version 4.992: Multithreaded scaling across multiple CPU cores is massively improved, without memory usage blowout. It can be configured to scale close to linearly for any number of CPU cores. In the Fastcode memory manager benchmark tool FastMM 5 scores 15% higher than FastMM 4.992 on the single threaded benchmarks, and 30% higher on the multithreaded benchmarks. (I7-8700K CPU, EnableMMX and AssumeMultithreaded options enabled.) It is fully configurable runtime. There is no need to change conditional defines and recompile to change options. (It is however backward compatible with many of the version 4 conditional defines.) Debug mode uses the same debug support library as version 4 (FastMM_FullDebugMode.dll) by default, but custom stack trace routines are also supported. Call FastMM_EnterDebugMode to switch to debug mode ("FullDebugMode") and call FastMM_ExitDebugMode to return to performance mode. Calls may be nested, in which case debug mode will be exited after the last FastMM_ExitDebugMode call. Supports 8, 16, 32 or 64 byte alignment of all blocks. Call FastMM_EnterMinimumAddressAlignment to request a minimum block alignment, and FastMM_ExitMinimumAddressAlignment to rescind a prior request. Calls may be nested, in which case the coarsest alignment request will be in effect. All event notifications (errors, memory leak messages, etc.) may be routed to the debugger (via OutputDebugString), a log file, the screen or any combination of the three. Messages are built using templates containing mail-merge tokens. Templates may be changed runtime to facilitate different layouts and/or translation into any language. Templates fully support Unicode, and the log file may be configured to be written in UTF-8 or UTF-16 format, with or without a BOM. It may be configured runtime to favour speed, memory usage efficiency or a blend of the two via the FastMM_SetOptimizationStrategy call. Experience/opinions welcome ...