We do an application that shows users their deals per week. There are all weeks from 2016 till 2040 year. For this we use ViewPager that get list of DateTime elements. Yes, it has a lot of elements. And due to DateTime element fragment in ViewPager create expandableListView. We supposed that ViewPager can reuse elements or at least delete elements that it does not use right now.
May be in original Android this thing has place, but in our project we have memory leaks. I mean this - we change fragment, memory increases AND NEVER decreases! We have created special single thread that call GC.Collect every 4 (four) seconds, but it is very bad idea. Unfortunately, in other way, memory will increase more and more.
And when we call notifyDataSetChanged() we get memory leaks too.
Please help us. Can you suggest another and good solution of it? (if code is needed I will show, but please say what exactly code you need)
Related
I'm relatively new to JavaFX and have written a small applet which launches a number of (typically between 3 and 10) sub-processes. Each process has a dedicated tab displaying current status and a large TextArea where the process output is appended to. For simplicity all tabs are generated on startup.
javafx.application.Platform.runLater(() -> logTextArea.appendText(line)))
The applet works fine when workloads on sub-processes are low-moderate (not many logs), but starts to freeze when sub-processes are heavily used and generate a decent amount of logging output (a good few hundreds of lines per second in total).
I looked into binding the TextArea to the output, but my understanding is it effectively calls the Platform.runLater() method so there will still be hundreds of calls to JavaFX application thread per second.
Batching logging outputs isn't an ideal solution either because I'd like to keep the displayed log as real-time as possible.
The only solution which I think might solve the problem seems to be dynamic loading of individual tabs. This would definitely prevent unnecessary calls to update logging textareas that aren't currently visible, but before I go ahead to make the changes, I'd like to get some helpful advice from you here. Thanks!
Thanks for all your suggestions. Finally got around to implementing a fix today.
The issue was fixed by using a buffer coupled with a secondary check for time lapse (maximum 20 lines or 100 ms).
In addition, I also implemented rolling output to limit the total process output to 1,000 lines.
Thanks again for your invaluable contribution!
I'm developing a mobile app using Flex and I have run into some problems using BlazeDS. Some users request a (relatively) pretty large amount of data from my server, which returns in about 2 seconds. The data consists of some pretty simple objects (Client, which has a name/phone/email, and a few other properties, some of which are other nested objects with more properties). The largest requests consist of no more than about 10,000 of these objects, which is only a few MB in size. The problem I am running into is that as soon as the server sends its response, the mobile screen locks up while the data is being processed. For 10,000 objects, this can take several minutes and sometimes even crash the device, and at best leave the user with a frozen screen the entire time. For the average user, it is at least 2-5 seconds of frozen screen. This is not only an issue for devices with limited capabilities. This also happens on my PC (i5 processor, 8GB RAM). From what I can tell, this downtime is taking place somewhere between when the device receives the response and when I can access the data. Setting a breakpoint on the first line of the following RemoteObject result handler has the screen lock up BEFORE it reaches the breakpoint:
protected function myResultHandler(event:ResultEvent):void
{
var result:ArrayCollection = event.result as ArrayCollection;
//Do other stuff here
}
I know very little about BlazeDS and AMF, so my only guess is that the freezing happens while the objects are being created on the device. Is there any way to speed up this process at all? Should I normally expect to see really poor performance like this? Any help would be greatly appreciated.
After a couple of hours digging around, I found the solution to my problem: On the server side, the objects I was sending had a ton of extraneous properties unrelated to the information I needed on the mobile app. In addition, there were helper methods on those classes in the form getMyHelper() which would attempt to generate a property on the Flex side. This resulted in a huge list of reference errors being thrown during the download since no properties with those names existed in the AS objects. I created stripped down 'lite' versions of the objects I needed sent across with no extra properties or methods. The massive lists now display nearly instantaneously after receiving the response from the server.
In Microsoft Project (MSP), is it possible to have two parallel/concurrent activities with the same resource assigned to both? For example:
The worker resource "matt" is assigned to both activities, hence the overallocation error showing in the info column (red human icon).
Why do I require such a structure you may ask? In reality, one task would continually be temporarily interrupted to do the other one, and vice versa. But in MSP, it would be counter-productive to do so. Hence, my simplified approach - parallel activities.
So how should I fix this issue?
Ignore it?
Allocate 50% of the resource to each (and fix up finish dates which are automatically extended by MSP?)
Or is there a better solution?
if they indeed overlap then the best way to put this in your project is to allocate 50% on each task. But why fix up finish date, the program will recalculate the new duration of the task based on the new work, while the allocation is lowered to 50% then the duration should double ... Or you can declare the task as duration driven if that is the case, for such tasks duration will stay as set though allocation is changed
I do not think there is a better solution. So solution number 2 that is adjusting assignment units is the best in your case.
My application is leaking a visual component called GraphViewer. Every time the user changes graphs a new viewer is created and the old one is removed from the stage and discarded. Yet memory seems to leak. When I use the Flex profiler to track loitering objects it shows that GraphViewer instances indeed leak, but when I examine the object references of the loitering viewers I see that all of them (except one) have 0 paths to GC root.
I take a memory snapshot after GC and then change the graph (create a new viewer) N times. Then I do GC, take another snapshot and look at loitering objects. I see N GraphViewer objects loitering, but N-1 of them actually have 0 paths and only one has anything actually referencing it.
Why is the Flex profiler showing objects as loitering when they cannot be reached from the GC root? Is the Flex profiler reliable?
First off, why do you need to create a new instance of your component when new data arrives? Seems a bit wasteful. It's better to reuse an instance than to create a new one.
Second, it's hard to answer your issue without code, but often times the reason why a view component is kept in memory is because someone either still have a reference to it or an event listener hasn't been cleaned properly.
And lastly, there has been a known bug in the GC for some time now (though I haven't tested it recently; been about a year since I could reproduce) where large memory 'islands' (think of a very large module) won't clean up properly because the round trip algorithm for the GC won't figure that it's disconnected from the rest. To alleviate that, you might want to implement an IDisposable interface where your 'parent' view calls a destroy function before removing from stage (which then propagates throughout the component and it's children to destroy as well).
Good luck.
We have a flex app that will typically run for long periods of time (could be days or weeks). When I came in this morning I noticed that the app had stopped running and a white exclamation point in a gray circle was in the center of the app. I found a post about it on the Adobe forums, but no one seems to know exactly what the symbol means so I thought I'd reach out to the SO community.
Adobe forum post: http://forums.adobe.com/message/3087523
Screen shot of the symbol:
Any ideas?
Here's an answer in the post you linked to from an Adobe employee:
The error you are seeing is the new
out of memory notification. It is
basically shielding the user when
memory usage gets near the system
resource cap. The best course of
action here (if you own the content)
is to check your application for high
memory usage and correct the errors.
If you don't own the content, it would
probably be best to contact the owners
and make them aware of the issue you
are seeing.
He also says this in a later response:
Developers can use the
System.totalMemory property in AS3 to
monitor the memory usage that the
Flash Player is taking up. This iwll
allow you to see how much memory is
used, where leaks are and allow you to
optimize your content based on this
property.
I work for a digital signage company and we have also came across this error, however, it is not only memory leak related because it can be caused by utilizing the vector code on that page provided. We have also noted that it occurs without any kind of memory spike whatsoever, and sometimes appears randomly. However we noticed that when we replicated the bug with the vector error, it was saying it was an out of memory error - which clearly was not the case.
In our internal tests we noted that this bug only occurs with flash player 10.1 and up, flash player 10 does not seem to have this issue. Further, there seems to be a weak connection between the error occurring and the use of video. I know this might not be too much help, but just thought you should know it is not only a memory leak related issue. I have submitted this bug to Adobe, and hopefully they resolve it soon.
This can occur when using a Vector.int which is initialized using an array of a single, negative int. Because of the way you initialize the vector class with code such as:
Vector.int([-2])
The -2 gets passed to the vector class as it's initial length like Array(5) would be. This causes an error somehow (and is not checked and raised as an exception).
I have also noted the issue repeating when passing negative values to length of a Vector.
A possible explanation would be that the vector tries to allocate the length its been given immediately.
Since the negative value is being forced into a uint, the negative value autumatically translates to a very large positive value. this causes the Vector to attempt allocation of too much memory (about 4GB) and hence the immediate crash.
if you pass a negative value to the length of an Array nothing happens, because apparently it does not attempt to allocate the length. but you can inspect the value and see that it is a very large positive number.
This explanattion is pure conjecture, I did not hear it anywhere. but it is consistent with as semantics and the meaning of the exclamation mark.
This said, I have search our entire code base for the use of the setter "length" and could not find it used with a Vector. Still, we are experiencing very often crashes of this sort - some of them are caused by actual high memory consumption (probably leaks) but other times it just happens when the memory is relatively low.
I cannot explain it. perhaps there are other operations that can potentially lead to allocation of large amounts of memory other the the setter "lenght"?