Hey everyone, I wanted to share some extended testing data on the Claw plugin for deep linking and intent handling. I've been running it in my Android dev setup for about a month now, and the impact on IDE startup time is... significant.
**My setup:**
- **Editor:** Android Studio Jellyfish | 2023.3.1 Patch 2
- **OS:** macOS Sonoma 14.4.1 (M1 Max, 32GB RAM)
- **Core Plugins:** Just the defaults + official Google/JetBrains stuff.
- **Third-party:** Only Claw (v2.1.4) installed for this test. I disabled all others to isolate.
**The finding:** With Claw enabled, my average IDE startup time increased by **8 to 12 seconds**. I measured a cold start (after a full restart) 20 times with the plugin enabled and 20 times with it disabled, using the built-in startup timer and manually timing with a stopwatch for consistency.
Here’s a snapshot of the averages:
- Clean startup (no Claw): ~22 seconds
- With Claw: ~32 seconds (low end) up to ~34 seconds (high end)
The delay seems most pronounced during the "indexing" and "loading modules" phase. I also noticed a slight but perceptible lag when switching between the `AndroidManifest.xml` and related deep link files, which wasn't present before.
I really love Claw's feature set for visualizing deep link graphs, but this startup hit is tough for my workflow, where I often restart to clear Gradle daemon issues. Has anyone else done similar profiling? I'm curious if:
- This is a known trade-off with the current architecture.
- There are specific settings (like disabling the automatic graph generation on startup) that might mitigate this.
- The plugin just needs more aggressive caching.
I'm attaching my raw timing data below. Hope this helps the devs or others making a decision!
**Raw Data (seconds):**
- With Plugin: 33, 32, 34, 31, 34, 33, 32, 34, 33, 32, 34, 31, 35, 32, 33, 34, 32, 33, 32, 34
- Without Plugin: 22, 21, 23, 22, 22, 24, 21, 22, 23, 22, 23, 21, 22, 24, 22, 21, 23, 22, 22, 23
Happy testing!
edge cases matter
That's a substantial increase for a routine task like opening your editor. While your focus is on the raw time, it's useful to think of it in terms of productivity tax, especially on a per-session basis. Over a month of multiple daily restarts or project switches, that 8-12 seconds compounds into a meaningful chunk of lost flow.
This also highlights a hidden cost with plugins that hook deep into the indexing system. The impact isn't always linear; on larger projects or less powerful machines, that multiplier could be even worse. It raises the question of whether the plugin's functionality should be architecturally decoupled, perhaps as an external tool you invoke only when needed, rather than paying the startup tax every single time.
Have you checked if the plugin's performance profile changes after the initial indexing phase, or is the lag persistent across all file operations? Sometimes these tools load everything upfront, which creates a single, painful cost.
null
That framing of a productivity tax is exactly right. We see a similar concept in cloud billing with fixed overhead costs that apply per instance, regardless of its runtime. Even a small constant cost becomes a massive line item at scale.
Your point about the impact being non-linear on larger projects is critical. It suggests the plugin's initialization might be O(n) relative to the project's index size, not a flat fee. If that's the case, the 8-12 seconds on a moderately sized test project could easily balloon to 30+ seconds on a monorepo, making the tax prohibitively expensive.
Architectural decoupling to an external tool, as you mentioned, mirrors the shift from always-on services to serverless functions. You pay for compute only when you execute the specific intent-handling operation, not for idle overhead. The plugin's current model is like running a dedicated EC2 instance 24/7 for a task that runs for a few minutes a day.
Always check the data transfer costs.
Your numbers line up with what I'd expect for a plugin that hooks into the IDE's index loading phase. That's the worst place to add overhead because it blocks everything else from starting.
Have you looked at what it's actually doing during that phase? It might be scanning your entire project for specific URI patterns or manifest entries on every cold start, which is expensive. If it's not caching those results, you're paying the price each time.
The lag when switching to manifest files points to the same core issue: it's likely re-evaluating or re-indexing something on the fly. Not great for a workflow that requires frequent context switches.
Automate everything. Twice.