Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load Algorithms, improve selection speed, particularly for Nexus files #8109

Closed
1 task done
NickDraper opened this issue Jun 7, 2013 · 2 comments
Closed
1 task done
Assignees
Labels
Framework Issues and pull requests related to components in the Framework High Priority An issue or pull request that if not addressed is severe enough to postponse a release.
Milestone

Comments

@NickDraper
Copy link
Contributor

This ticket is blocked by :

This ticket is blocks : TRAC7065

If we pass around an open file pointer to the FileCheck methods nexus loaders (and others) can use the open pointer to perform their tests, rather than each open the file themselves. This should be much faster.

Source email from James Lord:

If I have a script/algorithm to process a batch of runs and I write it in a generic 
way using Load(), it takes about twice as long as using the correct specific load 
routine such as LoadMuonNexus(). I suspect Load() is first opening the file to 
inspect the format then closing it and passing the filename onto the format-specific 
version, which opens it again and ignores any cached data.

I've checked with files from the local disk and those from a network drive 
(//hifi/data) and while the local files load faster there is still the same 
improvement to be had by switching to LoadMuonNexus().

In this case I am (intentionally) loading all spectra, and the logs, from muon 
Nexus files of about 750kbytes each (on disk).

Is there any improvement to be made such as caching the file or being able to 
"hint" to Load() that the next file in a sequence is almost certainly going to be 
the same file format as the last one it just loaded?

James Lord.
(Mantid 2.5.3 at present, Windows 7)

@NickDraper
Copy link
Contributor Author

This issue was originally trac ticket 7263

@NickDraper
Copy link
Contributor Author

@NickDraper NickDraper added High Priority An issue or pull request that if not addressed is severe enough to postponse a release. Framework Issues and pull requests related to components in the Framework labels Jun 3, 2015
@NickDraper NickDraper added this to the Release 2.6 milestone Jun 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Framework Issues and pull requests related to components in the Framework High Priority An issue or pull request that if not addressed is severe enough to postponse a release.
Projects
None yet
Development

No branches or pull requests

2 participants