6 Replies Latest reply on Mar 13, 2014 1:25 AM by David Miller

    Windows Mobile 6.5.3 Incremental Performance degradation

    David Miller

      I have an intriguing performance problem concerning an application in live trials.


      Unfortunately a significant performance issue is being seen once the device (MC55A0) has been in continual operational use for around 2 hours.  After 3 to 4 hours, it's unusable.  It's used for scanning and data capture. 


      The symptom of performance degradation is seen mostly in screen transitions. 


      When the device is loaded with the application and run for the first time, it takes approximately 1 second between screen transitions.  After two hours, the users are seeing around 30 seconds between screen transitions.  After 3 or 4 hours, two minutes.


      Other performance degradation symptoms are seen with the time taken for the application to respond to button presses, input field data loading (value defaults for example) and the spinning icon slows right down in between screen transitions.


      I have done a basic check of memory usage and CPU utilisation and can see no difference between a slow device and a performant device.


      However, if I terminate the application (Menu, Exit), the performance symptoms disappear immediately and reappear only after further continued use.  Also, if I perform a database reset (Rhom::Rhom.database_full_reset), after a period of a few minutes, the application performance issues disappear and again, only reappear after further continued use.  But, if the application database is preloaded with a significant amount of data, the performance problem is NOT apparent except after the above continued use.


      I was initially looking for coding problems but could not spot anything obvious.  But I am suspicious of the SQLite database due to the problem being resolved after database_full_reset, and since preloading the database does not exhibit any performance issues. 


      I am using JQM (yes I know this is not recommended on WM) however the customer is comfortable with the performance (and look) of the device when it is first used.  Since the application is a multipage application, there could be an issue with the continued reloading of the JQM JS libraries but I suspect this least due to the database_full_reset fixing the issue.


      Can anyone shed any light on the performance degradation over time and what it might be attributable to - whether SQLite, JQM, multi page, possible code issues (resources), config.xml, deeper memory/resource consumption issues, other etc?


      Any help appreciated and no idea is a daft one


      Rho V2.2

      Motorola MC55A0




      Scanning and Data Capture

        • Re: Windows Mobile 6.5.3 Incremental Performance degradation
          David Miller

          Also I have:


          $.mobile.ajaxEnabled = false;


          This is because some some screen transitions failed.

            • Re: Windows Mobile 6.5.3 Incremental Performance degradation
              Jon Tara
              Since the application is a multipage application, there could be an issue with the continued reloading of the JQM JS libraries but I suspect this least due to the database_full_reset fixing the issue.

              That doesn't make any sense. JQM JS libraries aren't reloaded with each page.


              I don't see what anything related to the database could possibly have any affect on jQuery Mobile.


              $.mobile.ajaxEnabled = false;

              Ah, well, in *that* case, JQM JS libraries *are* reloaded with each page, and is probably the cause of your performance problem.


              Really, if you have to disable Ajax, there isn't much point in using jQuery Moble. If transitions fail, just use transition "none".


              You can certainly find a pure CSS library that will give you similar appearance with much better performance.

                • Re: Windows Mobile 6.5.3 Incremental Performance degradation
                  David Miller

                  Thanks Jon.


                  I’ll try and enable Ajax and see what happens.  However, I’m really confused as to why the database_full_reset would resolve the performance issue.  Unless this simply frees up some application memory that allows it to continue without performance problems for a while longer.


                  I replicated the problem the customer is seeing by simply going from one screen to another and back again, 100 times.  I could see a marked change in performance.  Also when they do not transition between screens (I.e. When they are simply barcode scanning and there is only a web view.execute) the performance problem is not seen to get worse.  So this indicates your resolution may be the cause.


                  I could probably do with a diagnostic tool that runs on the device to check all resources.  I tried Application Verifier but could not get it to work on my Windows partition on Mac.  If anyone can recommend a tool to use, I’d appreciate it.

                    • Re: Windows Mobile 6.5.3 Incremental Performance degradation
                      Peter Arcuri

                      Perhaps the eMscript diagnostic tool can help identify what is going on under the covers. This tool will capture data such as memory, cpu, and other resources every minute and produce a processes dump every 15 minutes.  Running the tool on the device during before and after the condition occurs would create resource data and is located in the application/emscript folder.


                      Based on the default data capturing profile, the .csv file would contain the minute by minute resource snapshot while the .txt would contain the 15 minute processes dump (in separate folders). 


                      You can obtain the eMscript diagnostic tool from Motorola support centre.

                      • Re: Windows Mobile 6.5.3 Incremental Performance degradation
                        Jon Tara

                        FYI, the most common reason for disabling Ajax is not problems with transitions, but improper use of IDs in the HTML, and/or a lack of understanding of Ajax page loading. So, if you've had this turned off for a while, you might have been lulled into this trap.


                        Since JQM loads multiple pages into a single document, it imposes a constraint that is not immediately obvious. ID values in HTML must be unique within a document. We are used to thinking of a document as a "page", even though HTML actually doesn't define the word "page" and the concept of "page" really has no meaning in HTML. In order to perform a transition, the "old" and "new" pages have to both be present in the document at the same time.


                        The implied constraint here is that your ID values have to be unique across your entire project, and even then there are some cases where even that is not enough. (Reloading the same page!) So, my advise is to never use IDs at all in a JQM project.


                        This is easy to accomplish if you plan for it and design this way from the start. It can be very burdensome to fix after the fact, though.


                        Back to the subject, though. I assume the problem is as you have speculated - you are simply pushing memory capacity. If this is an issue on your platform, I would strongly urge you to dump jQuery Mobile. It isn't designed to work well on low-end hardware. Loading multiple pages into the document is an extravagance more appropriate for higher-end hardware. As well, jQuery, jQuery Mobile, and jQuery Mobile's CSS are quite large compared to other alternatives. Although the numbers might not seem that large in comparison to device memory, low-end devices do tend to allocate fewer resources to the browser/webview.


                        As well, jQuery Mobile does a significant amount of work upon initialization of every page. My experience is that at least on complex pages with input controls, the jQuery Mobile page initialization time far exceeds the time spent in the controller and Rhom fetching data and creating the HTML. You might spend a couple hundred mSec in the Controller, and then several seconds initializing the page in JQM.


                        JQM 1.4 improves on this quite a bit, but Rhodes has not yet adopted 1.4, and it is a very significant effort to move from <1.4 to 1.4, because there are a large number of breaking changes.


                        For low-end devices, keep it simple. I would avoid widgets altogether except for very specific use cases. You should be able to get by on just CSS (certainly you can use a small CSS framework) like millions of non-flashy websites. If you find you need a query library there are some lightweight, faster, alternatives to jQuery, such as Zepto, and many of are largely compatible with jQuery. (same API calls). I would urge you to use some query library if you are using a lot of Javascript, because it allows you to write much more terse code and deals with cross-browser compatibility issues.


                        Without Ajax page loading, you are loading JS and CSS with every page (document) and so it's important to keep it small. It still nets out of faster performance. Of course, that JS and CSS will usually be loaded from browser cache.

                          • Re: Windows Mobile 6.5.3 Incremental Performance degradation
                            David Miller

                            Hi Jon


                            Extremely good help and advice – as always.  I was certainly needing reminding that the IDs need to be unique across the whole project rather than just a ‘page’.   What you say makes perfect sense considering Ajax.


                            I turned off Ajax initially as the Scanner would not enable and some pages would not load (all possibly due to ID’s).  But also, perceived speed problems.  But I think this was a mis-perception.


                            Regarding dumping JQM, if I was starting this project now, I would certainly do so.  However, I’m partly under the direction of the Customer so there are constraints there.  BUT you are right – dumping JQM is the best way forward overall.  I do need to understand what replacing JQM entails in terms of my project (effort and time involved) I’m under pressure to simply resolve the performance problem.  I do use a fair amount of JS to manage the user input, etc etc so I’ll need to investigate Zepto and others properly.


                            I’m familiar with JQM and much of what we do here is JQM driven, but I’ll have a look at Zepto and other frameworks for this and other WM projects.  iOS and Android are obviously different in my current opinion.


                            Many, many thanks for the help and advice.  I do appreciate it.