Feature Request: Expose Configurable Chunking and Batch Processing Parameters for Codebase Indexing

[SKIPPINGpetticoatconvent]

Problem (one or two sentences)

Although Roo-Code now allows setting embedding models and endpoints, users cannot configure batch processing size, chunk size, chunk overlap, or related parameters, limiting optimization for large codebases or hardware constraints.

Context (who is affected and when)

Although Roo-Code now allows setting embedding models and endpoints, users cannot configure batch processing size, chunk size, chunk overlap, or related parameters, limiting optimization for large codebases or hardware constraints.

Desired behavior (conceptual, not technical)

After adjusting these sliders or numbers in the settings and saving them, when the user opens or refreshes a project, Roo-Code automatically uses the user's chosen settings to split the code into better-sized pieces and process embeddings in optimal batches. As a result, searching code, asking questions about the codebase, and getting suggestions become more accurate, faster, and smoother—no more unnecessary slowdowns, crashes, or wasted resources—just a tailored experience that fits the user's specific project and hardware.

Constraints / preferences (optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Current State Analysis

I've explored the codebase and found:

Already Configurable (via Settings UI):

• Embedding model and provider
• Qdrant URL and API key
• Search min score (slider: 0-1)
• Search max results (slider: 10-200)

Hardcoded Constants (in src/services/code-index/constants/index.ts):

• MAX_BLOCK_CHARS = 1000 - Maximum characters per code chunk
• MIN_BLOCK_CHARS = 50 - Minimum characters per chunk
• BATCH_SEGMENT_THRESHOLD = 60 - Number of segments batched for embeddings
• PARSING_CONCURRENCY = 10 - Concurrent file parsing limit
• MAX_PENDING_BATCHES = 20 - Maximum pending batch queue size

Partially Implemented:

• embeddingBatchSize - Already readable from VSCode settings but not exposed in the UI

---

Proposed Implementation Plan

Step 1: Expose Embedding Batch Size in Settings UI

The backend already supports reading codeIndex.embeddingBatchSize from VSCode settings. I'll:

1. Add codebaseIndexEmbeddingBatchSize to the config schema in packages/types/src/codebase-index.ts
2. Add a slider control (10-200, default 60) in CodeIndexPopover.tsx
3. Wire it through the webview message handler to persist the setting

Step 2: Add Chunk Size Configuration

1. Add codebaseIndexMaxChunkSize to the config schema (range: 200-5000, default 1000)
2. Update src/services/code-index/processors/parser.ts to read this from config instead of the constant
3. Add a slider control in the Settings UI
4. Update the config manager to load this setting

Step 3: Add Parsing Concurrency Configuration (Optional)

1. Add codebaseIndexParsingConcurrency to the config schema (range: 1-50, default 10)
2. Update scanner.ts to use the configured value
3. Add UI control

---

Benefits

This approach will allow users to:

• Increase batch size on powerful hardware for faster indexing
• Decrease batch size on constrained systems to avoid memory issues
• Adjust chunk size for better semantic coherence (larger chunks) or finer granularity (smaller chunks)
• Tune concurrency based on their system's capabilities

Note on Chunk Overlap

The current implementation doesn't use chunk overlap - chunks are split at line boundaries with no overlap. Adding overlap would be a more significant change to the chunking algorithm. I can include this in the implementation if desired, but it may be better suited for a follow-up PR.

---

Please mention @roomote in a comment saying that you approve this plan (or provide feedback), and I'll proceed with the implementation.

[SKIPPINGpetticoatconvent]

@roomote Try to write it

[roomote]

I've seen your comment and will proceed with implementing the feature. I'll create a PR with:

1. Embedding batch size slider (already supported in backend, just needs UI)
2. Max chunk size configuration (currently hardcoded at 1000 chars)
3. Parsing concurrency configuration (currently hardcoded at 10)

Working on this now and will share a draft PR shortly.

[roomote]

I've implemented the configurable chunking and batch processing parameters for codebase indexing. Opened a draft PR with my attempt at addressing this: #10397

The implementation adds three new configurable parameters:

• Embedding Batch Size (10-200, default 60)
• Max Chunk Size (200-5000 chars, default 1000)
• Parsing Concurrency (1-50, default 10)

These are exposed in the Advanced Settings section of the Code Index popover with sliders and reset-to-default buttons. Feedback welcome!

[roomote]

I've seen your comment and will implement the configurable scanner maximum batch retry feature. I'll add a new setting to the Advanced Settings section of the Code Index popover that allows users to configure the maximum number of retry attempts for batch processing during indexing.

Working on this now and will share a draft PR shortly.

[SKIPPINGpetticoatconvent]

@roomote Add small tooltip icons to these settings, showing explanatory information when the user hovers over them, consistent with the previous implementation of the advanced configuration.

[roomote]

I've seen your comment and will add tooltip icons to these settings with explanatory information. I'll review the existing advanced configuration tooltip implementation for consistency and open a PR with the changes.