Flush Windows File Cache

sweepHere 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.

(more…)

Efficient File Enumeration

MS-DOS_iconDelphi 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.

(more…)

Memory Managers and String Building

synscalemm[This is a guest post, written by Primož Gabrijelčičwww.thedelphigeek.com]

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.

(more…)

Boosting Work Classes with a mini Object Pool

gearsWork 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…)

TMonitor vs TRTLCriticalSection

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.

(more…)