I have developed checklist app for government internal use.
It has 250 fields in different tabular format.
What is happening is that loading of screen takes 10 second or more in 1.4 ghz quad core processor with 1 gb ram device also.
How to improve loading of static device or at least show indicator to user that user form is being load through some indicator?
Can I load static xml file with async task?
Does it improve perfomance?
IS there any option to load static UI incrementally once user scroll down?
Please note that there are no list view.
Only static view for lines and checkboxes and text views are there.
why dont you categorize these fields and keep in different activity so it will improve performance and application structure will be good.
Why not make a list view that has a custom check box row layout? It'll be much faster as it only loads what's on the screen. If you hide the dividers its practically the same assuming its a vertical list.
Related
Currently my network speed is about 1.5s per page if there are images in that page, If i move to different pages with image, audio and video file in it then loading of page takes around 2s to 2.5s. What i want to know is if there is a way to bring that loading time to minimum.
I am using Django, and Django-templates here to create such web application.
Since you are talking about images, audio and video, first I will play with the size and quality of the image, make some tests. For the audio and video you might want to use the attribute preload="none". This from the template. Another option is to upload image/audio/video by scroll, or paging. It is not a good practice to send all together. i.e: show 10/15 multimedia per page
From the view check the queries you are executing and the data structures you are using (memory consume is important, avoid huge lists and jsons). The same goes for the custom filters, if applicable.
I have a standalone javafx application that contains approximately 3000 Textfields (used for user input) divided in 10 pages created with FXML.
The navigation between pages is done either via Tabs or via ToggleButtons.
The problem is the switch time between the pages:
If I load all the controllers in memory, I get:
~2 seconds for an Intel Celeron at 1.6Ghz
<1 second for an i5
If I load the corresponding controller at switch time, ~1 second adds up in every situation.
When switching the pages I use:
borderPane.setCenter(controller.getNode()), so I don't reload everything, just the textfields grid is changed with another one.
No other computation is done at switch time.
can I improve somehow the switch time?
if I'm thinking at adding a loading indicator, how do I know when the page is ready and the indicator can be closed? (Something equivalent to onDomReady() in webbrowsers)
other ideas?
I have monodevelop 2.8 on top of monotouch 5 agains the Xcode 4.2 SDK. I have been having memory issues with my iPhone app. I have been struggling with identifying the cause, so I created a test app with a master detail view. I made a minor modification to the rootcontroller to have it show 5 root items instead of the default 1. Each click of the root item adds a new DetailViewController into the navigation controller.
controller.NavigationController.PushViewController (DetailViewController, true);
In my detail view controller I've added logic that simply take an input that governs the number of times a loop happens, and then a button to trigger the loop to occur and make a call to a REST based service. Very minimal code changes from the default.
Just running the example and looking at it in instruments I seem to be up to 1.2 MB of live bytes. I think launch the detail view by touching items in the root view controller and I get up over 2 MB. Rotating the display or triggering the keyboard to open gets memory up near 3 MB. I navigate back in the controller and open a different view from the rootviewcontroller and I can see the memory grow some more. Just moving in and out of views without even triggering my custom code I can get the memory use in instruments over 3 MB. I've seen my app receive memory warnings when being up over 3 MB before. My test detail view is very basic with a text box, a label, and a button that all have outlets on them. I was under the impression I don't need to do anything special to have them cleanup. However, I don't see live bytes drop in instruments.
As an additional test, I added a Done button. When the done button is pressed I go and use RemoveFromSuperview() on each outlet, Dispose(), and then set it to null. I see the live bytes drop. But that doesn't do anything for me if the back navigation is used instead.
I'm curious if anyone can verify my expectations of seeing memory drop. Not sure if using instruments to look at live bytes is even valid or not. I'd like to determine if my testing is even valid and if there are tips for reducing memory foot print. Any links to best practices on reducing the memory foot print are appreciated as I seem to be able to get the memory to climb and my app to start getting memory warnings just by navigating around between screens.
It's hard to comment without seeing the code for the test app. Is there any way you could submit a bug report to http://bugzilla.xamarin.com and attach your test project?
There's a developer on MonoTouch working hard to add additional smarts to the GC for MonoTouch for 5.2 that I'm sure would love to have more test cases.
I would also be very interested in looking over your test case.
I'm writing a MIDlet using LWUIT and images seem to eat up incredible amounts of memory. All the images I use are PNGs and are packed inside the JAR file. I load them using the standard Image.createImage(URL) method. The application has a number of forms and each has a couple of labels an buttons, however I am fairly certain that only the active form is kept in memory (I know it isn't very trustworthy, but Runtime.freeMemory() seems to confirm this).
The application has worked well in 240x320 resolution, but moving it to 480x640 and using appropriately larger images for UI started causing out of memory errors to show up. What the application does, among other things, is download remote images. The application seems to work fine until it gets to this point. After downloading a couple of PNGs and returning to the main menu, the out of memory error is encountered. Naturally, I looked into the amount of memory the main menu uses and it was pretty shocking. It's just two labels with images and four buttons. Each button has three images used for style.setIcon, setPressedIcon and setRolloverIcon. Images range in size from 15 to 25KB but removing two of the three images used for every button (so 8 images in total), Runtime.freeMemory() showed a stunning 1MB decrease in memory usage.
The way I see it, I either have a whole lot of memory leaks (which I don't think I do, but memory leaks aren't exactly known to be easily tracked down), I am doing something terribly wrong with image handling or there's really no problem involved and I just need to scale down.
If anyone has any insight to offer, I would greatly appreciate it.
Mobile devices are usually very low on memory. So you have to use some tricks to conserve and use memory.
We had the same problem at a project of ours and we solved it like this.
for downloaded images:
Make a cache where you put your images. If you need an image, check if it is in the cachemap, if it isn't download it and put it there, if it is, use it. if memory is full, remove the oldest image in the cachemap and try again.
for other resource images:
keep them in memory only for as long as you can see them, if you can't see them, break the reference and the gc will do the cleanup for you.
Hope this helps.
There are a few things that might be happening here:
You might have seen the memory used before garbage collection, which doesn't correspond to the actual memory used by your app.
Some third party code you are running might be pooling some internal datastructures to minimize allocation. While pooling is a viable strategy, sometimes it does look like a leak. In that case, look if there is API to 'close' or 'dispose' the objects you don't need.
Finally, you might really have a leak. In this case you need to get more details on what's going on in the emulator VM (though keep in mind that it is not necessarily the same as the phone VM).
Make sure that your emulator uses JRE 1.6 as backing JVM. If you need it to use the runtime libraries from erlyer JDK, use -Xbootclasspath:<path-to-rt.jar>.
Then, after your application gets in the state you want to see, do %JAVA_HOME%\bin\jmap -dump:format=b,file=heap.bin <pid> (if you don't know the id of your process, use jps)
Now you've got a dump of the JVM heap. You can analyze it with jhat (comes with the JDK, a bit difficult to use) or some third party profilers (my preference is YourKit - it's commercial, but they have time-limited eval licenses)
I had a similar problem with LWUIT at Java DTV. Did you try flushing the images when you don't need them anymore (getAWTImage().flush())?
Use EncodedImage and resource files when possible (resource files use EncodedImage by default. Read the javadoc for such. Other comments are also correct that you need to actually observe the amount of memory, even high RAM Android/iOS devices run out of memory pretty fast with multiple images.
Avoid scaling which effectively eliminates the EncodedImage.
Did you think of the fact, that maybe loading the same image from JAR, many times, is causing many separate image objects (with identical contents) to be created instead of reusing one instance per-individual-image? This is my first guess.
In an Eclipse RCP application I am trying to open many editors. It is a basically a tree with lot of nodes each of which opens an editor. When I open in access of 150 to 200 editors and try to open an editor for next treenode it doesn't open. Eclipse console shows "org.eclipse.swt.SWTError: No more handles". However if I close a few of already opened editors I am able to open as many new treenode editors.
I monitored the memory usage for javaw.exe; memory grows on opening of each editor but number of handles remain constant after a certain MAX. javaw.exe consumes around 120,000K when the error happens. The total memory consumed by all applications during error is 700,000K. And if I try to open a few more applications like IE it either doesn’t open or opens with lesser UI features due to shortage of system memory. And all this in spite of having 2GB RAM!
I also tried by increasing vmargs in eclipse memory settings but it wasn’t of much help either.
a) Is there a memory leak in my code? I don’t see it as handles remain constant after a certain MAX. As I understand, as editors are open, the SWT controls on it are not disposed until they are closed.
b) Whats the max. memory that can be used up by applications? As my RAM is 2GB and I see that my overall memory to all processes should be way better than 700,000K which I think is around 680MB.
a) Try Sleak. It can find GDI-leaks in your SWT-application
b) You can try to change the maximum GDI handles or User object in the registry. See here and here more information.
You also might want to try to create a vitual tree so that only tree nodes that are shown are created.
I cannot answer specifically your question, but it seems to me you are running into the maximum limit of open files a process can have at any time (judging from the "handles" term, which often refers to open files, much like file descriptors in Unix). It would be a matter of operating-system-level user permissions/capabilities then. The allowed number of open files has nothing to do with memory size.
Handles refers to file handles (open file references) and is controlled by the operating system. It's not typically a user changed setting because keeping lots of file handles open indefinitely hogs OS resources.
This question falls into the If you have to ask, you're probably doing something wrong category. ;-)
Your best bet here is to open the file, read it and then close it. Then reopen the file when you need to write out the changes. You may need to use a locking mechanism as well if you are worried about concurrent edits.
If you don't want to change too much logic it may help to open+read+close each file as you put it int he tree and then reopen (for write) the one(s) that are currently in the user's active view, closing them as the user navigates away.
Windows deals with several kinds of handles, e.g. executive handles (files, threads), GDI handles (fonts, brushes, device contexts), user handles (windows, menus, most native controls, images). For most of these handles, there's a per-process and an overall system limit which has nothing to do with the amount of RAM available in your system. E.g. due to historical reasons, there's a limit of 10000 user handles per process and a limit of 32000 user handles per desktop session. See http://msdn.microsoft.com/en-us/library/ms810501.aspx for an in-depth explanation of handles.
So first you need to make sure that you are not leaking any handles, e.g. using Sleak. Then you need to be aware that SWT uses at least one user handle for each widget (yes even for plain Composite objects). If you have a big application with lots of widgets, you'll hit the limit of 10000 user objects. I wrote a short blog entry about what we did to work around this limit in our product: http://www.subshell.com/en/subshell/blog/investigating-user-handles-with-the-swt-detective100.html. I also hacked the SWT Spy into a tool which allows me to investigate the widget tree of our application, to find places to reduce the widget count. The download link for this tool is in the blog entry.