-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory usage #39
Comments
Generally calling |
There does not seem to be a leak but just lots of memory allocated (Leaks in C# are very difficult without win32 api/interop/com usage). My observations come from the memory diagnostic tool. My EveMon is very sluggish when moving it around the screen (the collect was one of the things i tried, altough the memory usage shrunk quite a bit, it did not solve my issue). Neither does the profiling the app. Basically I'm trying to find where it spend it's time I'm aware of the collect not being something you should call but it's one of the ways to make garbagecollection a bit more aggressive. |
Digging some more reveals that EveMonClient.TimerTick has quite some subscribers/handlers attached to it from all over EveMon. EveMonClient.TimerTick .GetInvocationList().Count should get some info on what's going on. My guess is UpdateOnOneSecondTick() is trying to invoke them back2back as fast as possible, [edit] TimerTick has 340-350 delegates attached to it which are executed every second.[/edit] |
EVEMon uses a lot of custom controls with overridden render methods -- I suspect if there is a performance issue when moving it, it could very well be related to that in addition to the subscribers/handlers. If you can get some performance logging when the stuttering happens, that would be very helpful for tracing down the root cause. |
Times vary a lot (most are a few ms but some are much longer, I've seen up to 5000ms which should create issue with a 1s timer).
The profiler does not return useful data for me, not the single spot where the product times*time explodes. I'll experiment a bit more with doublebuffering & disabling of redraws. |
Left it to run for some hours and it becomes sluggish again (trails behind when moving the window around). All ThreadSafeInvoke are now at least 250+ ms. Also the code does not run every second anymore, which is strange. 0d 5h 36m 25s > EventHandlerExtensions.ThreadSafeInvoke - ThreadSafeInvoke: 359 ms for 350 delegates |
Did some experimenting. Changed the code in EVEMon.Common\Extensions\EventHandlerExtensions.cs so it emits some timing data. I also added a Application.DoEvents() call to pump messages but not sure if really needed. [edit] Without the DoEvents() execution times seem to be down to the 10ms range [/edit] The top 3 where EVEMon\CharacterMonitoring\CharacterMonitor*.cs In these classes methods UpdateFrequentControls() & UpdateInfrequentControls() I commented out the SuspendLayout()/ResumeLayout() pairs (and in \CharacterMonitorBody.cs also the Refresh() just after the ResumeLayout). This creatly improved performance (around 70-80ms now). Also note that in EVEMon.Common\Controls\ControlExtensions.cs I disabled the bodies of SuspendDrawing() and ResumeDrawing(). Finally in Dispatched.cs OneSecondTickTimer_Tick body I changed to:
However there seems to be no overrung as the trace statement wasn't execute. This should indicate the timer happlily slips seconds every now and then.
|
Forget the line 'and in \CharacterMonitorBody.cs also the Refresh() just after the ResumeLayout'. This Refresh() seems neccesary for the queue and skills lists to blink the actively trained skill. Would be better to only paint the item being changed. |
I added a
GC.Collect();
statement to the EveMonClient_TimerTick of mainwindow.cs (after the two udates methods) and it seems to lower the memory usage quite a bit (a steady 371M on my laptop). Without the forced garbase collection is peaks to over 0.5G before lowering to around 450M of memory in use.
The text was updated successfully, but these errors were encountered: