perf(intellij): implement Gson singleton service to reduce memory allocation

[houssemzaier]

Description

The IntelliJ plugin currently creates new Gson instances repeatedly throughout the codebase. This pattern is an anti-pattern for heavy objects in IntelliJ plugin development and causes unnecessary performance overhead:

• Memory waste: Each Gson instance requires significant memory allocation due to reflection-based type adapter initialization
• GC pressure: Short-lived Gson objects increase garbage collection frequency
• CPU overhead: Repeated reflection operations on every instantiation
• Against IntelliJ best practices: Heavy objects should follow the Light Service pattern

Current State

Common problematic patterns in our Kotlin codebase:

• Config file parsing: Gson() created per file read
• Message handling: Gson() created per IDE ↔ Core communication
• JCEF bridge: Gson() created per React ↔ Kotlin message exchange
• State persistence: Gson() created for each save/load operation

Proposed Solution

Implement JsonService as an IntelliJ Light Service following platform best practices:

1. Create application-scoped singleton service with @Service(Service.Level.APP) annotation
2. Provide two Gson instances:
   • Standard compact formatter for production use
   • Pretty-printed formatter for debugging and config files
3. Add convenience methods for common JSON operations
4. Migrate all existing Gson() and GsonBuilder().create() calls to use the singleton

Implementation Location:

• Service: extensions/intellij/src/main/kotlin/com/github/continuedev/continueintellijextension/services/JsonService.kt
• Pattern: Light Service (zero XML configuration, auto-discovered by platform)
• Scope: Application-level (single instance per IDE session)
• Thread-safety: Gson is inherently thread-safe

Expected Benefits

• Reduced memory footprint: Single initialization instead of repeated allocations
• Lower GC pressure: Fewer short-lived objects
• Better CPU efficiency: Reflection-based initialization done once
• Platform compliance: Follows IntelliJ Platform SDK recommendations for resource-intensive objects

References

• IntelliJ Platform Plugin Services
• Gson Thread-Safety Guarantees

Implementation Plan

I'm willing to implement this optimization and will submit a PR after this issue is reviewed. The implementation will:

• Create the JsonService Light Service
• Migrate all existing Gson instantiations
• Ensure no functional regressions (all tests pass)
• Follow Continue's contribution guidelines

Labels: performance, enhancement, intellij
Priority: Medium-High

[Patrick-Erichsen]

Hey @houssemzaier thanks for the writeup! I recently did a deep dive on this issue after reading through #8085 and came to a somewhat similar conclusion, ie that the freezing issues are a result of us sending too many messages from the IDE to the webview, and each messages lives on the JVM heap.

Could you provide a more concise summary of your research and how you came to your conclusion? This report seems accurate but is pretty clearly AI generated so I'd like to get a better sense of your understanding of the problem since this would be a very large and sensitive fix to attempt.

[houssemzaier]

Hey @Patrick-Erichsen, totally fair question - let me get straight to the technical point.

My Background: I'm a senior Android/Kotlin developer working on a Continue fork for my organization. I've dealt with memory optimization in Kotlin/Android for years, so this pattern immediately jumped out when profiling our deployment.

What I Found:

I was profiling our IntelliJ plugin's memory usage and noticed repeated Gson allocations in the heap dumps. Traced it to these hotspots:

1. Message handling (Core ↔ IntelliJ communication layer): Every message creates a new Gson() instance in the deserialization path
2. JCEF bridge (React ↔ Kotlin message exchange): Each message instantiates Gson
3. Config parsing: Every time .continuerc.json is read, new Gson instance

The Problem:

Gson's constructor is expensive - it builds an internal type adapter registry via reflection. Creating it repeatedly:

• Wastes memory through redundant allocations
• Triggers unnecessary reflection on every instantiation
• Creates GC pressure in the already memory-constrained JCEF environment

In high-frequency message scenarios (Core ↔ IDE communication), this overhead compounds quickly.

Regarding #8085:
You're right that message volume is the root cause of the performance issues. My fix addresses the symptom (inefficient object creation), not the root cause (message frequency). But it's still worthwhile - we can't eliminate all messages, so we should at least handle them efficiently.

My Approach:

@Service(Service.Level.APP)
class JsonService {
    val gson: Gson = GsonBuilder().create()
    val prettyGson: Gson = GsonBuilder().setPrettyPrinting().create()

// Then replace:
// val data = Gson().fromJson(json, MessageType::class.java)
// With:
// val data = service<JsonService>().gson.fromJson(json, MessageType::class.java)
}

I've already mapped out the locations that need updating. Happy to start with a small PR (just the service + 2-3 critical paths) so you can review the approach before touching the whole codebase.

Let me know if you want me to share the specific file paths I found, or if you'd prefer a different approach.

[Patrick-Erichsen]

Thank for for the quick and detailed follow up! This makes sense, I believe we only recently transitioned to using Gson extensively, which about lines up with when we started getting these issues.

I think we should start with those 2-3 critical paths and go from there. My hunch is that if this is indeed the root cause then those paths are accounting for 99% of Gson instantiations.

Looking forward to this fix!

[houssemzaier]

Sounds good! I'll focus on the high-frequency message handling paths first. Will have a PR ready in the next few days.

[sestinj]

🎉 This issue has been resolved in version 1.32.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[sestinj]

🎉 This issue has been resolved in version 1.29.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[sestinj]

🎉 This issue has been resolved in version 1.5.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[sestinj]

🎉 This issue has been resolved in version 1.6.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀