Skip to content

perf: speed up "Save all" for very large numbers of open files #3039

Open

Description

@Palloxin

Check for existing issues

  • Completed

Describe the feature

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

No response

Activity

  1. 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
  2. added
    Low priorityA task or issue that is less urgent or important than others.
    area:editorFeedback, improvements related to the editor (code editing, editor iteration, formatting, etc)
    on Nov 12, 2026
  3. bajrangCoder commented on Nov 12, 2026

    @bajrangCoder
    Member

    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.

  4. 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
  5. removed
    area:editorFeedback, improvements related to the editor (code editing, editor iteration, formatting, etc)
    on Nov 12, 2026
  6. bajrangCoder commented on Nov 12, 2026

    @bajrangCoder
  7. Palloxin commented on Nov 12, 2026

    @Palloxin
    ContributorAuthor

    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

  8. bajrangCoder commented on Nov 12, 2026

    @bajrangCoder
    Member

    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.

  9. Palloxin commented on Nov 12, 2026

    @Palloxin
    ContributorAuthor

    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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Low priorityA task or issue that is less urgent or important than others.area:performanceSpeed, lag, memory and startup timeenhancementNew feature or request

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions