You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
perf: speed up "Save all" for very large numbers of open files #3039
The performance has already been improved once making it acceptable currently, nice.
This is the current performance on my device after the improvement:
jdjdjd.mp4
(400 files take 59 seconds to be saved all)
However I still wish it was faster because I personally deal with mass text replacements on 2000+ files. So of 400 files per minite, 5 minute for 2000 files......
I wish it was faster, if the code allows it.
If applicable, add mockups / screenshots to help present your vision of the feature
changed the title [-][performance] Improve mass-save of files further[/-][+]perf: layout reacts slowly when the soft keyboard opens or closes[/+]on Nov 12, 2026
Thanks for the follow-up and the timing numbers. Most of that time is Android's storage layer writing each file, and that depends heavily on the device. Saving more files at once wouldn't help much on lower-end phones and could even slow things down, so we're keeping the current limit. We may still trim some of the work done per file, but don't expect a big jump. Saving 2000+ files at once is an edge case, so we're marking this low priority.
changed the title [-]perf: layout reacts slowly when the soft keyboard opens or closes[/-][+]perf: speed up "Save all" for very large numbers of open files[/+]on Nov 12, 2026
I have the experience of using Termux to mass replace text. With a command the whole "search, replace/regex, and save all" all took under 25seconds for 1500chaps (only with very light regex patterns).
cidkd.mp4
(this is an old video, probably applied yo only 500 chaps or so, i dont remember)
Of course Acode is acode with its enviroment and technical limitations, I understand I understand. I just wonder if there is a better chance to make the mass-save alone faster, having thag termux experience.
Note, if u interested in termux methods, beware because that method has a deep flaw termux/termux-app#4908
I have the experience of using Termux to mass replace text. With a command the whole "search, replace/regex, and save all" all took under 25seconds for 1500chaps (only with very light regex patterns).
cidkd.mp4
(this is an old video, probably applied yo only 500 chaps or so, i dont remember)
Of course Acode is acode with its enviroment and technical limitations, I understand I understand. I just wonder if there is a better chance to make the mass-save alone faster, having thag termux experience.
Note, if u interested in termux methods, beware because that method has a deep flaw termux/termux-app#4908
I am just proposing mindlessly
Termux is fast because sed edits files directly on disk with no editor in between. In Acode, every replaced file is opened as a tab and each write goes across the WebView ↔ Android bridge, so Save all alone can’t get close to that. The tabs are there on purpose: they let you review the changes and undo them before saving. Without them, one wrong regex could overwrite hundreds of files. A possible way forward is an optional “replace without opening tabs” mode for Search in files (#3028), for people who accept that it can’t be undone. Save all itself is unlikely to get much faster.
I have had the experience (react native) of seeing the simple "progress listener" put there to slow down the process itself. And the dev simply resolved by making a timed listener, every 10 seconds it tries to "listen" and updates the progress, every 10 seconds. It didnt require the code to update the progress at each incremental. He joked that maybe the progress listener is like your employee breathing down your neck at every step.
Is possible to gain at least a 5% perf improvement with this method on Acode?
Activity
[-][performance] Improve mass-save of files further[/-][+]perf: layout reacts slowly when the soft keyboard opens or closes[/+]bajrangCoder commentedon Nov 12, 2026
Thanks for the follow-up and the timing numbers. Most of that time is Android's storage layer writing each file, and that depends heavily on the device. Saving more files at once wouldn't help much on lower-end phones and could even slow things down, so we're keeping the current limit. We may still trim some of the work done per file, but don't expect a big jump. Saving 2000+ files at once is an edge case, so we're marking this low priority.
[-]perf: layout reacts slowly when the soft keyboard opens or closes[/-][+]perf: speed up "Save all" for very large numbers of open files[/+]bajrangCoder commentedon Nov 12, 2026
Palloxin commentedon Nov 12, 2026
I have the experience of using Termux to mass replace text. With a command the whole "search, replace/regex, and save all" all took under 25seconds for 1500chaps (only with very light regex patterns).
cidkd.mp4
(this is an old video, probably applied yo only 500 chaps or so, i dont remember)
Of course Acode is acode with its enviroment and technical limitations, I understand I understand. I just wonder if there is a better chance to make the mass-save alone faster, having thag termux experience.
Note, if u interested in termux methods, beware because that method has a deep flaw termux/termux-app#4908
I am just proposing mindlessly
bajrangCoder commentedon Nov 12, 2026
Termux is fast because sed edits files directly on disk with no editor in between. In Acode, every replaced file is opened as a tab and each write goes across the WebView ↔ Android bridge, so Save all alone can’t get close to that. The tabs are there on purpose: they let you review the changes and undo them before saving. Without them, one wrong regex could overwrite hundreds of files. A possible way forward is an optional “replace without opening tabs” mode for Search in files (#3028), for people who accept that it can’t be undone. Save all itself is unlikely to get much faster.
Palloxin commentedon Nov 12, 2026
I have had the experience (react native) of seeing the simple "progress listener" put there to slow down the process itself. And the dev simply resolved by making a timed listener, every 10 seconds it tries to "listen" and updates the progress, every 10 seconds. It didnt require the code to update the progress at each incremental. He joked that maybe the progress listener is like your employee breathing down your neck at every step.
Is possible to gain at least a 5% perf improvement with this method on Acode?