Commit 22f6b7c
committed
Reuse the MEF session across reads
_read_segment_file built a fresh MefSession on every call. Parsing the session
metadata takes ~38 ms on the 194-channel testing recording and does not depend
on the requested range, so a short window cost as much as reading the whole
file: get_data(start=0, stop=100, picks=[one channel]) was 39.0 ms, of which
38.0 ms was metadata and 0.02 ms was data.
Caching it in _raw_extras, which _ReadSegmentFileProtector already exposes:
full read (194ch x 98000) 490.5 -> 451.5 ms 1.1x
1000 samples, all channels 47.2 -> 7.2 ms 6.6x
1000 samples, 4 channels 39.7 -> 0.19 ms 206x
100 samples, 1 channel 39.0 -> 0.07 ms 590x
100 epochs of 2 s 4895.6 -> 914.5 ms 5.4x
The epoching row is the one that matters in practice -- every windowed read
paid the full metadata parse, so epoching, plotting and scrolling were all
dominated by it.
MefSession and RawMef are both picklable, so caching in _raw_extras keeps
raw.copy(), copy.deepcopy() and pickling (n_jobs) working; all four are checked
to return bit-identical data, as are crop and preload=True.
Not fixed here: the remaining 451 ms of a full read is pymef decoding channel by
channel. pymef does not release the GIL -- reading the channels across 4-14
threads measured 0.99x -- so that floor cannot be moved from MNE.1 parent 3e783e6 commit 22f6b7c
1 file changed
Lines changed: 17 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
233 | 233 | | |
234 | 234 | | |
235 | 235 | | |
236 | | - | |
237 | | - | |
238 | 236 | | |
239 | 237 | | |
240 | | - | |
| 238 | + | |
241 | 239 | | |
242 | 240 | | |
243 | 241 | | |
| |||
257 | 255 | | |
258 | 256 | | |
259 | 257 | | |
| 258 | + | |
| 259 | + | |
| 260 | + | |
| 261 | + | |
| 262 | + | |
| 263 | + | |
| 264 | + | |
| 265 | + | |
| 266 | + | |
| 267 | + | |
| 268 | + | |
| 269 | + | |
| 270 | + | |
| 271 | + | |
| 272 | + | |
| 273 | + | |
260 | 274 | | |
261 | 275 | | |
262 | 276 | | |
| |||
0 commit comments