-
Notifications
You must be signed in to change notification settings - Fork 3
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
Make cleanup stages of processing multi threaded #8
Comments
Yes, processing speed for sets of >10k images can and should be improved. Not writing multiple log files associated with each image is one way to save a lot of time on input/output - the working directory will contain "a_few times more_than_10k" files less. (These image logs are mostly useful at the debugging stage rather than for mass processing.) Can you please specify what exactly do you mean by "removing images" stage? What VaST is writing to the terminal at this time? |
Less files would certainly help! Also make multithread what is now single thread such as:
|
I'm sorry, so far I was unable to get a speed-up from parallelizing these steps. Basically, all of them are limited by the need to read every lightcurve ( In the mean time, I've made some minor improvements in the lightcurve reading routine (an option not to parse the whole VaST-format lightcurve string if we are interested only in the first three columns "JD mag err"), that provides a small, but measurable speed-up on large sets of lightcurves. |
Thx for looking into this! As discussed above, did you also look at limiting log files? Will help with speed but also dirs get very slow with that many files :). I will leave this open in case you want to add something but feel free to close if you feel this issue is done. |
removing images and everything that comes after that is not multi threaded and takes a very long time for 35k images.
The text was updated successfully, but these errors were encountered: