As GCBASIC has grown, so has the complexity of the Preferences Editor—and unfortunately its performance has started to show the strain. Functionally it still does everything we need, but it has become noticeably slow as more features have been added over time.
I’m looking for a volunteer who would be willing to help rewrite or refactor the Preferences Editor with a focus purely on performance.
No functional changes are required; this is strictly about improving responsiveness, structure, and efficiency.
I don’t believe this is a huge job. Modern AI tools can assist in identifying bottlenecks and suggesting improvements—the real work will be in adapting those recommendations and testing the updated editor.
We will continue using SharpDevelop IDE for this task. It’s open source, stable, and still perfectly suitable for the project.
If you’re interested in contributing or want to discuss the scope, please reply here. Any help would be greatly appreciated.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you. All sorted. The 'Save operation' from 9secs to 20secs to 8ms!!!
WOW!
It was taking longer to save the preferences than compile a source project!!
Root Cause of Slow INI Save in Editor Preferences
The SavePreferences method in the Windows application was taking ~9–20 seconds to write a small (~18KB) INI file with 53 sections and 366 settings. Diagnostics revealed:
Primary Bottleneck: System.Environment.SetEnvironmentVariable (with User target) was called inside the inner For Each s In section.Settings loop—once per matching setting (e.g., "GCBASIC_INSTALL_PATH"). This Win32 API writes to the registry/user profile, taking 100–500ms+ per call (worse with AV/network profiles), compounding to 20s.
Secondary Issue: Uncached GetPref loops in the header (~19s in one run), scanning all settings repeatedly.
Why Hidden: The loop looked innocuous, but the API's cost scaled with iterations; small files amplified the per-call overhead.
The Fix
Defer Env Var Set: Collect the value once (last match wins), then set it once outside the loop in LoadPreferences (infrequent vs. saves). Use EnvironmentVariableTarget.Process for in-app speed (instant; swap to User for persistence if needed, but async it).
Add Caching: Dictionary cache for GetPref (key: "Section.Pref", O(1) lookup; populated post-load, updated on SetPref).
Optimize I/O: Build full content in StringBuilder (pre-allocated), write once via File.WriteAllText (skips env var line entirely).
Optional Refresh: Added UpdateEnvVars() for mid-session changes (call after SetPref if needed).
Result: Save time dropped to ~8ms (header: 4ms, build: 0ms, write: 0ms). Load handles env once (~0ms with Process target). No functional changes—pure perf win.
Code snippets and full diff available if needed! (Tested on .NET 3.5/SharpDevelop.)
👍
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi everyone,
As GCBASIC has grown, so has the complexity of the Preferences Editor—and unfortunately its performance has started to show the strain. Functionally it still does everything we need, but it has become noticeably slow as more features have been added over time.
I’m looking for a volunteer who would be willing to help rewrite or refactor the Preferences Editor with a focus purely on performance.
No functional changes are required; this is strictly about improving responsiveness, structure, and efficiency.
For anyone interested, the current code can be viewed here:
https://sourceforge.net/p/gcbasic/code/HEAD/tree/utils/Programmer%20Editor/ I will provide all the tools and code needed to support this activity.
I don’t believe this is a huge job. Modern AI tools can assist in identifying bottlenecks and suggesting improvements—the real work will be in adapting those recommendations and testing the updated editor.
We will continue using SharpDevelop IDE for this task. It’s open source, stable, and still perfectly suitable for the project.
If you’re interested in contributing or want to discuss the scope, please reply here. Any help would be greatly appreciated.
Thanks!
Thank you. All sorted. The 'Save operation' from 9secs to 20secs to 8ms!!!
WOW!
It was taking longer to save the preferences than compile a source project!!
Root Cause of Slow INI Save in Editor Preferences
The
SavePreferencesmethod in the Windows application was taking ~9–20 seconds to write a small (~18KB) INI file with 53 sections and 366 settings. Diagnostics revealed:System.Environment.SetEnvironmentVariable(withUsertarget) was called inside the innerFor Each s In section.Settingsloop—once per matching setting (e.g., "GCBASIC_INSTALL_PATH"). This Win32 API writes to the registry/user profile, taking 100–500ms+ per call (worse with AV/network profiles), compounding to 20s.GetPrefloops in the header (~19s in one run), scanning all settings repeatedly.The Fix
LoadPreferences(infrequent vs. saves). UseEnvironmentVariableTarget.Processfor in-app speed (instant; swap toUserfor persistence if needed, but async it).GetPref(key: "Section.Pref", O(1) lookup; populated post-load, updated onSetPref).StringBuilder(pre-allocated), write once viaFile.WriteAllText(skips env var line entirely).UpdateEnvVars()for mid-session changes (call afterSetPrefif needed).Result: Save time dropped to ~8ms (header: 4ms, build: 0ms, write: 0ms). Load handles env once (~0ms with Process target). No functional changes—pure perf win.
Code snippets and full diff available if needed! (Tested on .NET 3.5/SharpDevelop.)