feat(emmylua_ls): show progress percentage while indexing workspace

[Davidyz]

This PR adds support for sending percentage progress when initializing the codebase.

[gemini-code-assist]

Summary of Changes

Hello @Davidyz, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the user experience of the EmmyLua Language Server by introducing detailed progress reporting during its initial workspace indexing. Instead of a static message, users will now observe a dynamic percentage indicating the completion status of the indexing process, providing better feedback and transparency during startup.

Highlights

• Progress Reporting: Implemented percentage-based progress updates during the workspace indexing phase of the EmmyLua Language Server. Users will now see a real-time percentage indicating how much of the codebase has been indexed.
• File Processing Logic: Refactored the file loading mechanism to process files individually within a loop, allowing for granular progress reporting, rather than a single bulk update.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces progress percentage reporting during workspace indexing, which is a great user experience improvement. However, the current implementation introduces a performance issue by updating files one by one within a loop, which can be slow for large projects. I've provided a suggestion to refactor this to use a more performant bulk update approach while still reporting progress. The suggestion also includes a fix for the percentage calculation to ensure it reaches 100%.

[gemini-code-assist]

The current implementation updates files one by one within a loop by calling update_file_by_path. This is inefficient because update_file_by_path triggers index removal and update operations for each file, which can be very slow for large workspaces.

A more performant approach is to first iterate through the files to update them in the Virtual File System (VFS) while reporting progress, collect their IDs, and then perform a single bulk operation to update the index for all files at once.

Additionally, the progress calculation (index as u32) * 100 / file_count will never reach 100%. The suggested code fixes this by using index + 1 to ensure the progress completes at 100%.

    let files: Vec<emmylua_code_analysis::LuaFileInfo> = collect_files(&workspace_folders, &emmyrc);
    let file_count = files.len();
    if file_count > 0 {
        let mut file_ids = Vec::with_capacity(file_count);
        let vfs = mut_analysis.compilation.get_db_mut().get_vfs_mut();

        for (index, file) in files.into_iter().enumerate() {
            let (path, text) = file.into_tuple();
            status_bar.update_progress_task(
                ProgressTask::LoadWorkspace,
                Some(((index + 1) as u32 * 100) / file_count as u32),
                Some(format!("Indexing {} files", file_count)),
            );
            if let Some(uri) = emmylua_code_analysis::file_path_to_uri(&path) {
                let file_id = vfs.set_file_content(&uri, text);
                file_ids.push(file_id);
            }
        }

        mut_analysis.compilation.remove_index(file_ids.clone());
        mut_analysis.compilation.update_index(file_ids);
    }

[CppCXY]

This is an incorrect use of the API. Loading all files together and performing out-of-order analysis aligns with the reality of Lua. Introducing progress reporting and loading them separately not only reduces performance but also leads to incorrect results.

[Davidyz]

I see. I have another design: create a new function EmmyLuaAnalysis::update_files_by_uri_with_progress that accepts a callback. We can then pass a closure function that updates the progress bar. The update_files_by_uri_with_progress function can use the same design as the other batch update functions and handle the update_index and remove_index altogether. Would that be a acceptable solution?

[CppCXY]

Your current progress report only monitors the construction of the syntax tree, which constitutes a very small part of the analysis process. The time spent reporting progress may far exceed the time required to build the syntax tree. This is an unacceptable performance degradation. Progress bars should not be used to monitor performance-intensive analysis stages.

[Davidyz]

Indeed. I noticed that the progress will stay at 100% for a while, which means the progress representation is inaccurate.

Progress bars should not be used to monitor performance-intensive analysis stages.

The progress percentage is a notification, so it doesn't need to wait for a response, and therefore shouldn't be a performance bottleneck. Also, if a task doesn't take very long, there's no point of using a progress bar, because you'll hardly be able to see the "progress".