rlm-tools-bsl

The benchmark measures the performance of several core operations:

• Initialization and internal index construction
• Module searching (find_module)
• BSL parsing (extract_procedures, find_exports)
• Caller searching (find_callers)
• Text search (grep)
• XML metadata parsing (parse_metadata_xml)
• Event subscriptions and scheduled jobs
• Register movements

Benchmark Fixture

The fixture/ directory contains a minimal synthetic 1C configuration in CF format (~20 files) designed to use realistic BSL patterns. It includes:

• 2 Common Modules (with #Область, Export, and cross-module calls)
• 1 Document (attributes, tabular sections, OnPosting, OnFill, and forms)
• 2 Catalogs (XML metadata + object modules)
• 1 Information Register (dimensions, resources, record set module)
• 1 Accumulation Register (dimensions, resources)
• 1 Event subscription
• 1 Scheduled job
• 1 Enumeration

The BSL Method Index is a pre-built SQLite database that contains a table of all procedures and functions within a 1C codebase, along with an optional heuristic call graph. It enables near-instantaneous answers to queries such as "what methods are in this module?", "who calls this function?", or "what are the export procedures for this object?" without needing to re-read files from disk.

Key Features

• Symbol Table: Uses regex-parsing to populate a methods SQLite table (e.g., ~569K methods in ERP).
• Call Graph: Uses heuristic regex to populate a calls SQLite table (e.g., ~4.5M edges in ERP).
• Full-Text Search: Uses SQLite FTS5 with a trigram tokenizer and BM25 ranking via the search_methods function for substring searching on method names.
• Metadata Support: Includes 17 metadata tables (e.g., ES, SJ, FO, HTTP, WS, XDTO, synonyms, regions, forms, etc.) and an index_meta table.
• Zero Dependencies: Built with pure Python and the SQLite standard library.
• Performance: Significantly reduces MCP (Model Context Protocol) calls and improves quality for smaller AI models.

RLM (Repository-Level Machine-coding) is an approach where an AI agent explores a repository directly in real-time. Instead of relying on pre-indexed vector databases (RAG), the agent performs search queries, reads files, and analyzes structure on demand.

Key Benefits for 1C (BSL) Codebases:

• Token Efficiency: Instead of reading a 2000-line file into the context, the agent can call tools like extract_procedures(path) to get only the signatures, or read_procedure(path, "ProcedureName") to get only the specific body. This typically saves 25-95% of context tokens.
• No Pre-indexing: Unlike RAG, there is no need for time-consuming preliminary vectorization or heavy infrastructure maintenance.
• Sandbox Execution: The agent sends Python scripts to the server, which execute in a sandbox. Only the print() output is returned to the agent's context, ensuring only filtered, relevant data is consumed.

In the default process mode, workers use a limited queue to bridge WARNING+ logs to the parent's server.log. This prevents IPC bloat by intentionally excluding DEBUG logs.

Key constraints and safety behaviors:

• Validation: The parent process re-validates all bridged logs. It enforces a limit of $\le 20$ records, a maximum length of $\le 300$ characters per record, and checks for printable code points. Violations trigger a SandboxProtocolError.
• Data Format: Logs are added to existing init_ok and execute_result frames using the log_records additive key. This is a non-breaking protocol update.
• Lifecycle: Startup logs are read once by the start-boundary. Execute-boundary logs are drained in a finally block around every backend.execute attempt to ensure logs are captured even during parallel shutdowns or lazy restarts.
• Limitations: The bridge does not guarantee delivery of runtime warnings issued after the last successfully received frame (e.g., during a hard timeout, worker_error, or worker loss).

If your source directory is inside a git repository, index update automatically uses git to identify changed files instead of scanning the entire filesystem. This works even if the .git directory is located above the source directory (e.g., in an EDT project).

How it works:

1. The git_head_commit (SHA) is stored in index_meta during build or update.
2. During the next update, the tool checks for a git repository and the git command in PATH.
3. It calculates a delta of all files changed since the saved commit (including committed, staged, unstaged, and untracked files).
4. It selectively updates BSL tables and metadata tables based on the file extensions found in the delta.

Requirements for Git acceleration:

• The source directory must be within a git repository.
• The git command must be available in PATH.
• A valid git_head_commit must exist in index_meta.
• The saved commit must exist in the git history.
• The builder_version must match the current version (version mismatches trigger a full rebuild).

When rlm_start detects a valid index (FRESH, STALE_AGE, or STALE_CONTENT), it connects helpers via an IndexReader. This transforms slow filesystem/XML operations into near-instantaneous SQL queries.

The BSL Method Index maps how methods are called within the codebase. To maintain accuracy and prevent false positives, the indexer uses a tiered resolution strategy for callee_key:

• local: A bare call like B() refers to a method within the same module as the caller.
• common_exported: A qualified call like A.B() refers to an exported method of a common module A (categorized as category=CommonModules, module_type=Module, is_export=1).

Important Note on Non-Resolved Calls: Object/manager calls (e.g., Справочники.X.Метод, Контрагент.Метод) and platform/external methods are intentionally not resolved (callee_key IS NULL). This prevents false associations. When a call cannot be resolved, the system falls back to a name-based match to ensure recall is not lost.

Resolution aggregates are tracked in index_meta via calls_total and calls_resolved.