Persistent file handles in VFS write path

[kounelisagis]

Every VFS::write() to a local file opened and closed the file descriptor (POSIX) or HANDLE (Windows) on each call. For write patterns with many small sequential writes (e.g., tile-at-a-time ingestion), the syscall overhead adds up significantly.

This change introduces persistent file handle caching at the local filesystem layer. The fd/HANDLE is opened on the first write(), kept alive across subsequent writes to the same path, and only fsync()'d and closed on flush(). The destructor cleans up any handles that were not explicitly flushed.

Standalone microbenchmark (macOS, Apple Silicon) comparing per-write open/close versus cached file handle:

Workload	Before	After	Speedup
1,000 × 4 KB writes	36.7 ms	17.2 ms	2.1×
5,000 × 4 KB writes	224 ms	94.6 ms	2.4×
10,000 × 512 B writes	217 ms	66.5 ms	3.3×

Measured with 10 trials (3 warmup) writing sequentially to a single file using pwrite(), comparing per-write open()/close() against a single cached fd, without fsync between writes (only at final flush).

The performance improvement increases as write size decreases (i.e., when the workload is more syscall-dominated), which matches the typical compressed-tile scenario.

Ref: #5732 (comment)
Closes CORE-497

---

TYPE: IMPROVEMENT
DESC: Persistent file handles in VFS write path.

[teo-tsirpanis]

Can you share your benchmark code? How many threads does it use to write files?

[teo-tsirpanis]

If we want to fix redundant file opens, we should more comprehensively refactor the VFS write API into something like this, which is much more performant and maintainable:

VFS vfs;
auto writer = vfs.create_writer(uri);
writer.write(buf1, len1);
writer.write(buf2, len2);
writer.write(buf3, len3);
writer.flush();

The existence of global¹ state in the VFS (and the class design that forces it) is an identified problem of this part of the library, and doubling down on it is not a move in the right direction, and will lead to bugs, performance issues², and more technical debt down the road.

Footnotes

1. insofar as across operations in each VFS instance ↩

2. I am not sure that performance would improve in real-world multi-threaded scenarios, due to the increased synchronization. ↩

[teo-tsirpanis]

This looks like a bad idea, and subverts the operating system's file locking semantics. What would happen if another thread is writing to a file inside the directory at the same time?

[teo-tsirpanis]

The struct should have a destructor (and be un-copiable and immovable).

[teo-tsirpanis]

The newly added logic should be moved to local.cc as much as currently possible, to reduce duplications across POSIX and Windows.

[teo-tsirpanis]

Suggested change

open_files_.clear();

No need to clear the map; it's going to be freed very soon either way.