Skip expensive parser gem YARD generation when RBS collection available - #1339
Open
apiology wants to merge 2 commits into
Open
Skip expensive parser gem YARD generation when RBS collection available#1339apiology wants to merge 2 commits into
apiology wants to merge 2 commits into
Conversation
Building YARD documentation for the parser gem takes over a minute on a cold cache, while its RBS collection types already describe the API. Caching parser measured 73.13s with YARD and 0.08s without. PinCache.suppress_yard_cache? reports true for a gem named in YARD_SUPPRESSED_GEMS whose RBS types resolved. Every place that decides to build YARD pins now consults it: DocMap#cache, Shell#cache, the named-gem path in Shell#gems, and Shell#do_cache. DocMap#deserialize_combined_pin_cache treats a suppressed gem as having an empty YARD half rather than an uncached one, so combined pins still get written and the gem stops reading as uncached on every load. The trade-off is coverage: parser yields 9,175 combined pins with YARD and 178 from RBS alone. Much of that gap is likely private and generated node classes, but that has not been verified against what users complete on.
undercover reported the method as 0.0% covered on this branch. The existing #cache and #gems examples reach it only through a subprocess shim, so none of its lines record coverage. The new examples call the private method directly with a stubbed Workspace, RbsMap and PinCache, and let the real PinCache.suppress_yard_cache? decide: a suppressed gem whose RBS collection resolves skips the YARD build, an unresolved cache key does not, and a gem outside the suppression list does not.
apiology
changed the title
apiology
changed the title
apiology
marked this pull request as ready for review
September 6, 2026 17:54
This was referenced Sep 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem: Caching the
parsergem spends over a minute building YARD documentation that its RBS types already describe, and every cold cache pays it.Solargraph resolves
parserthrough RBS on every one of those runs, so the YARD pass is largely redundant work sitting between the user and a usable cache.Solution:
PinCache.suppress_yard_cache?reports true for a gem named inYARD_SUPPRESSED_GEMSwhose RBS types resolved, and the four places that decide to build YARD pins —DocMap#cache,Shell#cache, the named-gem path inShell#gems, andShell#do_cache— skip the build when it does, taking that same command to 0.593s.Verified that Solargraph (an extensive parser gem user) is not affected in typechecking by the removed YARD information.
🤖 Generated with Claude Code