You should not be alarmed if your charting application appears to use a large amount of memory. Modern operating systems aggressively allocate memory to running processes. From the operating system's perspective, there's no point in taking memory away from a process until another process needs it. Because of this, you don't get a clear picture of how much memory your app is really using by looking at task manager. Memory usage will also not grow linearly as you add more charts because the browser will optimize and re-use.
Your operating system's task manager does not provide any real insight into actual memory footprint due to the above. You'll get a better picture of actual memory usage by using Chrome's built in task manager, which measures the actual performance and memory usage for each page (tab, iframe, etc).
If the heap grows continually, and never retreats, then there may be an actual leak (a stale reference). Charting library leaks can generally be traced to two possibilities: (1) a reference to an entire stx object that is no longer used (such as when switching views in a SPA) or (2) a reference to a masterData or dataSet outside of the chart. Everything else in the chart is too small to create a leak of any significance.
DOM is also memory intensive and web components particularly so. So the memory footprint for ChartIQ's full UI is going to be much larger than the core library. Third-party libraries, such as React, and frameworks, such as Angular and Vue, gobble up memory as well because they have so many scopes and closures tucked away behind the scene.
In principle, you should never attempt to manually force a garbage collection. This can cause frozen user interface at inopportune times. The V8 (or other) engine is going be be optimized beyond what a developer can manually improve upon.
If memory footprint is a concern, the best way to reduce is to use smaller masterData and to write lean UI.
Example: Chrome Performance Tab :