-
-
Notifications
You must be signed in to change notification settings - Fork 79
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
Optimized / Faster recording speeds? #235
Comments
Currently HLAE only writes out the images on the drawing thread, meaning 1 image at a time. I wouldn't expect writing multiple images being notably faster on Windows 10, since it uses operating system file functions to write them, but I don't know to be honest. We would have to gather data / clues on this. |
Not sure how relevant this is, or may shed some light on how data is sent through the system: |
Merging this into #295, thus closing. |
Is it possible to optimize the way the images (and/or videos) are being written on the drive in order to make use of the full capabilities of the drive?
A drive is the fastest when reading or writing in a sequential order + making use of many "channels" (queue depths) on the drive controller, and using more CPU threads, as far as I understand it. I don't know what the limitations are in the Source engine, but would it be possible to change (increase) compared to what is being used now?
I think the most common applications can use up to ~8 queue depths, but most modern SSDs can handle up to 32 or possibly more. Is this something that can be exploited at all, or is there a hard engine cap?
The text was updated successfully, but these errors were encountered: