A cold run on a spinning disk waited on the disk twice over. The CBF header
scan read 256 kB from every frame on eight threads that each strode through
their own share of the sweep, so they drifted apart and the scan became a
seek storm (34 s for 2400 frames here); and after it, the pre-scan and the
first-pass indexing touch a few hundred frames and leave the disk idle until
the first image loop reads everything at seek-bound rates.
- ReadAhead (reader/): once the dataset is open, rugnux starts eight threads
that read the data files - HDF5 data files (legacy, VDS or the integrated
master) or the per-frame CBF/marCCD/SMV files - in 4 MB pieces taken
strictly in order, into a throwaway buffer. One stream reads this disk at
125 MB/s, eight in-order streams at 190 MB/s, 32 at 157 MB/s. It never gets
more than a quarter of MemAvailable (GlobalMemoryStatusEx on Windows, 4 GiB
where there is no figure) ahead of what ReadRawImage has handed out, so a
dataset bigger than the cache does not evict its own start, and it stops
with the reader. Plain ifstream reads: portable, no POSIX calls.
- Header scans (CBF, marCCD, SMV) hand the files out in order from an atomic
counter (sweep::ForEachInOrder) instead of striding: 18 s -> 12 s for 2400
cold CBF headers. The CBF header is first read with a 16 kB probe and again
with the old 256 kB one only when the separator is not in it, so the parsed
header is exactly what it was: 12 s -> 6 s.
Output unchanged: p.hkl, p.mtz and p_unmerged.mtz md5-identical to the
rc173 baseline on 6toc (CBF, 2400 frames, 6.0 GB) and 9q41 (HDF5 VDS, 900
frames, 5.1 GB), and on 6z9g (HDF5, 12.8 GB) to the unmodified branch; myob
(p.hkl p.mtz p_P1.mtz p_unmerged.mtz) md5-identical to the reference.
Measured cold (files evicted with POSIX_FADV_DONTNEED before every run),
same code without this commit vs with it, on a shared box (load 20-70, other
agents reading the same disk, so single runs scatter by +-20 s):
6toc wall 61.7/62.7 -> 49.3/49.8 s (clean pairs); all data resident
after 62/51/50 -> 45/41/42 s
9q41 wall 67.3 -> 57.8 s (clean pair); resident after 58/46/43 -> 48/37/35 s
6z9g resident after 81 -> 69 s
The first image loop can look slower with this in CBF runs: the old 256 kB
header probes pulled ~70% of the data in as kernel readahead, so the old
loop started warm - after a 34 s header scan instead of 10 s.
Warm (myob, NVMe, cached): 19.35/20.00 s without, 19.76-20.16 s with; the
read-ahead then only copies 9.3 GB out of the page cache, 0.44 s wall and
3.4 CPU-s measured standalone.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D1G8gJVAy6gp1K5Dz3NE5C
87 lines
4.3 KiB
C++
87 lines
4.3 KiB
C++
// SPDX-FileCopyrightText: 2026 Filip Leonarski, Paul Scherrer Institute <filip.leonarski@psi.ch>
|
|
// SPDX-License-Identifier: GPL-3.0-only
|
|
|
|
#pragma once
|
|
|
|
#include <map>
|
|
#include <memory>
|
|
#include <optional>
|
|
#include <string>
|
|
#include <vector>
|
|
|
|
#include "../writer/HDF5Objects.h" // HDF5ReadOnlyFile, HDF5VirtualDatasetMapping, HDF5DataSetLayout
|
|
#include "../common/JFJochMessages.h" // FileWriterFormat, HDF5DataSourceMessage
|
|
|
|
// Turns a global image number into the HDF5 file + local index that physically holds its pixels,
|
|
// for all three on-disk layouts (legacy linked data files, VDS, contiguous/integrated). This is
|
|
// the part of the reader whose "links to files stay" constant: it knows where the raw images
|
|
// live, independent of which master file the per-image metadata is read from.
|
|
//
|
|
// Open data-file handles are cached, so scanning many images (e.g. reprocessing) does not reopen
|
|
// the same file on every read. HDF5 is not thread-safe, so every call must be made with the
|
|
// global hdf5_mutex held by the caller; the locator does no locking of its own.
|
|
class HDF5ImageLocator {
|
|
public:
|
|
struct Location {
|
|
std::shared_ptr<HDF5ReadOnlyFile> file;
|
|
uint32_t local_index = 0;
|
|
// Path the file was opened from. Needed to open it a second time as a plain file, for the
|
|
// positional reads HDF5ImageSource does outside the mutex.
|
|
std::string path;
|
|
// Where the images sit INSIDE that file. /entry/data/data everywhere DECTRIS writes, but a
|
|
// VDS names its source dataset and is free to name another one, so take it at its word.
|
|
std::string dataset = "/entry/data/data";
|
|
// Channel to read when the dataset is 4D, [image, channel, y, x], as the DECTRIS "hdf5 nexus
|
|
// v2024.2 nxmx" format writes it (one channel per threshold). Only the first channel of the
|
|
// master is read.
|
|
hsize_t channel = 0;
|
|
};
|
|
|
|
// One data file of a legacy multi-file dataset, with the dataset the master's link names
|
|
// inside it - the same "take the link at its word" the VDS branch already does.
|
|
struct LegacyFile {
|
|
std::string path;
|
|
std::string dataset;
|
|
};
|
|
|
|
// Layout description, filled by the reader once the master file has been parsed. All paths
|
|
// are absolute: legacy data files and VDS mapping filenames are resolved relative to the
|
|
// master before being handed over, so the locator never deals with relative paths.
|
|
struct Layout {
|
|
FileWriterFormat format = FileWriterFormat::NoFile;
|
|
HDF5DataSetLayout data_layout = HDF5DataSetLayout::CONTIGUOUS;
|
|
std::shared_ptr<HDF5ReadOnlyFile> master_file;
|
|
std::string master_filename;
|
|
std::vector<LegacyFile> legacy_files;
|
|
size_t images_per_file = 1;
|
|
std::vector<HDF5VirtualDatasetMapping> vds_mappings;
|
|
};
|
|
|
|
void Configure(Layout layout);
|
|
void Clear();
|
|
|
|
// Resolve a global image number to {file, local index}. Throws if the image is not covered
|
|
// by the layout. Does not bounds-check against the total image count - the caller does that.
|
|
Location Resolve(int64_t global_image) const;
|
|
|
|
// The files that hold the pixels, in image order: the data files of a legacy or VDS dataset, the
|
|
// master itself when the images are in it.
|
|
std::vector<std::string> DataFiles() const;
|
|
|
|
// Source mapping for re-writing a derived file (e.g. _process.h5) so it links back to the
|
|
// original pixel sources rather than to a master. total_images is supplied by the caller.
|
|
// stride is the step between consecutive images of the derived file in the SOURCE: image i of the
|
|
// output comes from source image first_image + i * stride. It has to match the stride the caller
|
|
// processed with, or the pictures and the per-image analysis in the derived file describe
|
|
// different frames.
|
|
std::vector<HDF5DataSourceMessage> GetSourceMapping(uint64_t first_image,
|
|
std::optional<uint64_t> image_count,
|
|
uint64_t total_images,
|
|
uint64_t stride = 1) const;
|
|
|
|
private:
|
|
Layout layout_;
|
|
mutable std::map<std::string, std::shared_ptr<HDF5ReadOnlyFile> > file_cache_;
|
|
std::shared_ptr<HDF5ReadOnlyFile> OpenCached(const std::string &path) const;
|
|
};
|