Here is a small utility I made whose purpose is to flush (empty) the Windows file cache. It can also flush and purge memory working sets, standby and modified lists.
It can be useful to reduce memory usage of a particular VM (on a host with dynamic memory) or for testing and bench-marking purposes.
Delphi offers two ways of enumerating files in a directory and its sub-directories, the first is the classic (and buggy) FindFirst/FindNext, the second is IOUtils TDirectory.GetFiles and not very efficient.
Here is why and how I implemented DWScript‘s dwsXPlatform.CollectFiles, and a tip about getting a small system-wide boost as a bonus.
[This is a guest post, written by Primož Gabrijelčič, www.
One thing interested me since I started reading Eric’s series on string concatenation performance – how would different memory managers compare in a multi-threaded scenario. Today I decided to spend an hour finding out…
edit 18/11: the tests were run with debug mode, which affected TTextWriter very negatively (TWOBS is also affected a negatively, but less, and StringBuilder and Trivial aren’t affected much). I’ll be repeating tests with more memory managers and in more stable conditions in the next few weeks.
After looking at String concatenation and String Building in Delphi, and as a conclusion, it’s time to have a brief look at what happens in multi-threaded settings, such as in a server pushing JSON, XML or some other text data.
As a followup to the String Concatenation article, let’s take a look at a less trivial case: what if instead of concatenating a couple strings, you want to concatenate a few hundred?
Sounds like a task at which TStringBuilder should excel, but one should never assume, and always measure.
You may all know about String concatenation in Delphi, but do you know about the implicit String variables the compiler may create for you?
Along with the implicit variables come implicit exception frames, and a whole lot of hidden stack juggling, which can quickly become hidden complexity bottlenecks.
Work and processing classes are typically short-lived, created to perform one form of processing or another then freed. They can be simple collections, handle I/O of one kind of another, perform computations, pattern matching, etc.
When they’re used for simple workloads, their short-lived temporary nature can sometimes become a performance problem.
(more…)
Implementing an efficient worker thread pool in Windows can be achieved through the use of IOCP, which is the barbaric acronym for (just as barbaric) Input/Output Completion Port API introduced by Microsoft a while ago.
To make use of IOCP, one has to deal with further barbaric API functions, but the principles are (somewhat) more civilized, and the implementation is quite straightforward.
In this new episode of the TMonitor saga is a comparison of its locking features vs TRTLCriticalSection, aka the OS-supported critical section mechanism. Is it fair? is it fast?
Fairness means that if you have several threads attempting to lock the same resources, they’ll all get a chance and none of them gets the lion’s share. In other words, that there are no race conditions.
Speed is obvious, it’s about the overhead the locking mechanism incurs.
Edit 2013-08-24: looks like the issue discussed here should be resolved in XE5, cf Monitoring the Monitor by Allen Bauer.
The built-in time-stepping support for the upcoming release of