Posted 7 years ago by Clint Brown - VP Development, eSSETS, Inc.
Version: 1.4.0005
Avatar

I have noticed that after an extended period of time that Code Writer starts to slow down. For example, opening a document takes several seconds rather than a fraction of a second, despite the fact that I use a solid state drive. Switching between documents also slows down.

Under extreme circumstances I also start having problems with other applications. For example, I start losing my internet connection.

My work habit is to leave Code Writer running all of the time so that it's ready to go when I am, so the only time it restarts is when I am rebooting.

I started keeping a log of the number of open files and the amount of memory in use as shown by Task Manager. Even after a relatively short period I started noticing memory usage creeping upward.

1/10/2013 7:33 PM - 3 open files, 66.1 MB

1/10/2013 9:13 PM - 14 open files, 105.9 MB

1/11/2013 9:39 AM - 6 open files, 147.1 MB

I had planned to keep a longer history, but this seems to be enough evidence that there's a problem.

FYI, the amount of disk space consumed by the last 6 open files is about 100 KB. I mention this just to indicate I don't think it is the size of the files that is causing the large amount of memory usage.

Although I am on the latest release, I did notice the slowdowns in v1.3. I believe it isn't something that just started with the latest release. It just took me a while to figure out why my computer was acting wacky.

Please let me know if there is any way I can help track this down.

Comments (2)

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Clint,

Thanks for telling us about this.  After doing some quick testing, I believe the documents are persisting in memory, even after being closed.  There isn't a good memory profiler yet for WinRT but we will do our best to track down what is holding onto the references.  We'll let you know what we find.


Actipro Software Support

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Clint,

We've put quite a few hours into researching this more.  The main problem is that there is no good tooling at the moment for detecting memory leaks in WinRT.  One available tool is PerfView from Microsoft, and it doesn't give much useful info at all.  We contacted the company that makes the normal .NET memory profiler we use and they have a WinRT-compatible beta version coming in several weeks.  We are on the list to get that.  We also found that JustTrace recently added some memory profiling for WinRT, and while it's not nearly as good as the other normal tool we use, it's better than PerfView.

At least what we can glean from these tools is that might be running into the property changed events not getting released from our page view models.  We found this Connect bug that someone else filed on a similar issue, which seems to be a bug in WinRT:

http://connect.microsoft.com/VisualStudio/feedback/details/761770/metro-apps-with-c-heavily-leaking-memory

That may be part of the reason our document instances build up over time.  We've changed some things internally that might help with the scenario.  There still seem to occasionally be objects held that both tools indicate are being held from within WinRT (not our code) and we're not sure how to handle those random scenarios.  Even when this happens though, we've made updates to minimize the amount of held memory.

Our internal updates will be in the next version.  We will look more in depth again once we get the new version of .NET Memory Profiler that supports WinRT.  If you continue running into the sluggishness, you may need to occasionally close down the app and restart it.


Actipro Software Support

The latest build of this product (v3.3.0029) was released 8 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.