Windows 8 optimize

My first Windows 8 application: Performance problems

Justin James discusses the trials and tribulations of week three of his Windows 8 Metro/WinRT application development project.

In last week's column, I described replacing the sample data sources in my Windows 8 Metro/WinRT application with connections to the Microsoft Research OData source. This week's work on the "MSR Browser" project was eventful, but I hit a big wall.

First, I started working on the search system; it turns out to be pretty painless. I have code written, but I have not been able to test it because of some issues that I will discuss in a bit.

Next, I made the necessary changes to the UI. This was a cinch, because there is a common styles file in the project's "Common" folder, and all of the templates used by the various pages for item and group display are in there. I was able to remove the useless images, but it didn't help the performance at all.

Performance has been the big problem. I keep getting an error about "exceeding my quota" when my data source populates itself. It's the kind of error I expect from a file system, but I'm not using the file system. Research showed this was a covered up out of memory error, and suggested the issue was that the page file was too big. Quick peeks at Task Manager showed the app was consistently crashing at about 300 MB of memory usage, but the machine was running at only 46% memory use. More fine-grained profiling showed a really strange thing: The downloaded data on one "group" of data was roughly 5 MB of memory, and the object to store it sucked up another 5 MB of memory -- that made sense. But, when I added the in-memory "group" to the internal list of groups, it consumed an additional 40 MB of memory. Clearly, something was wrong.

I need to do additional work to find out what's going wrong, but my deep suspicion is that the Metro UI bound to the list object is the issue. I reached out to Microsoft for help, and I hope to have a solution to report next week. I do not want to leap to conclusions until I discover what's happening. I could be to blame, though I am worried that something in the binding process may be multiplying the memory usage of a data object by a factor of eight.

Unfortunately, because of this issue, I have been unable to test my code for the search functionality. So far, it has been a snap to implement searching. To do it, I added an optional parameter to my "GetGroups" method (I renamed it "GetData" while I was there) to accept a query. When the text is loading if the query string exists and isn't null or empty, I alter the URLs that fetch the items for individual groups to have "/?search=" and the query added to it, as per the FAQ for the service. I added another group to the list called "All" and whenever I add an item to a group, I also add it to "All." The item's data still shows that it belongs to a specific group, but now it also can be shown on the "All" page, which is nice.

I look forward to working with Microsoft to figure out the performance issues, and I will hopefully be passing on what I learn next week.


Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.


Justin James is the Lead Architect for Conigent.


just wondering if anyone else agrees, and i will state up front this is a guess on my part, i dont have any real evidence for it... but it makes sense to me... I notice that in a lot of microsoft applications & even in parts of the operating system, they keep getting the same things wrong, and they might just be little things, but it is this attention to detail that is lacking, and potentially causing issues for not just users, but also coders. For example: the way that their systems deal with language is i think pretty weak. When you install any flavour of Windows, you have to tell it where you are located, and what language you want as well as keyboard layout... yet, having given it this information, it still has no idea what language i want when i install MS Office, and by default sets it as English (US) instead of English (Australia), and even then what it does is give me the wrong dictionary, because what it thinks is our Australian spelling of words is completely incorrect, we are closer to the UK than US on spelling (officially), and to some of us this matters. But, let's go deeper... why doesnt it just treat English as a base language, and then let me choose dialects to add to that dictionary, and then allow me to prioritize my spelling & grammar accordingly? ...and I think the answer to that is that they havent developed their object heirarchy in such a way that would allow it. that may seem like a little thing, but i think it is a big thing, because if your object heirarchies are unsophisticated, they will also be inflexible from a coding point of view, and anything innovative anyone tries to do will thus lead to problems. but there is another example of this too, with MS Outlook, and how it deals with signatures in HTML email... If I copy & paste MS Word formatted stuff into the signature design area of outlook, I lose all my formatting, and I cant do half the things I could do anywhere else... sometimes it wont even accept stuff from the clipboard (from memory)... so why is that? Surely that little design space for a signature should just use some common elements from word & share the clipboard & the formatting as everything else seems to? ...but no, it doesnt. again this may seem like a small thing, but that's not the point about how big or small each issue is, the point is that there are HEAPS of these, ie: no consistency & no sophistication at this level of detail. So it seems like Microsoft develop these really amazing potentialities, and then fail to keep their focus in the minutiae. I may be wrong about all this, it is just the impression i get... but i would like to see MS stop trying to develop a new Win8 interface & all that BS, and instead focus on getting all of these little bits of detail sorted out... and I think what they would find, if they bothered to do it, is that it would translate to more sales way better than a new interface would... because this means stability, flexibility, and sophistication, not just in Windows & Office, but in everything else that is developed for it... and that is the kind of thing that gets noticed, when you bother to fix this stuff instead of just looking for another way to bill people again for a new edition with some fancy bells & whistles on the front.