I am developing one Blackberry application. In that application i am using lot of images both downloading from server as well as inside application using images for designing image button. My application working fine until continuously using 3 to 4 minutes.After that my application performance was too bad. My question is how to optimize memory to improve my application performance?
Thanks in Advance.
A pure guess - you are keeping the downloaded images in RAM, even if you don't use them on your current screen. If this is the case, then try to save them to the file system and read only those you're actually use for the current screen.
Unfortunatelly we can only guess, while it'd be much better to do it in a professional way. First of all you should detect your real reason. For this you should monitor your app to see what kind of objects eat most of the memory. And also how memory state changes in time. I work in JDE and it has a built-in tool for such kind of monitoring: 'View' > 'Object Statistics' (or 'Memory Statistics'). To activate those items you have to start your app in debugger. When you know the reason, you can go further and actually fix your code.
Use Eclipse Blackberry plugin profiler to find out if its memory or cpu performance issues.
If there are images in resources you are using constantly for UI elements, it's better to load them on app start and save them into some static constants. This way you will save CPU from loading images from resources.
Also consider convert images in resources into PNG with the 565 colorspace
Related
I have an OS X Cocoa cpplication (10.8-10.9) that opens very large NSDocument (Core Data backed) files that are about 2 GBs or bigger. This takes about 20-40 seconds with the initial load of the document, but then is pretty snappy. The 20-40 seconds doesn't exactly jive with a good UI experience, so I'd like to fix that.
I would like to either A) make the document opening faster, or B) show a "loading" screen.
I'm wondering what (if anything) folks have done to A) make opening a core data document faster (even if its doing stuff in the background) or B) display a splash screen / progress bar during the opening process.
WRT to B) (not a 2-part question, really, just wanted to demonstrate I have do research) showing a splash screen by creating methods in the NSDocument class works if calling during: windowControllerWillLoadNib and windowControllerDidLoadNib methods, but only after the first document has been opened (I'm sure there is a workaround). Either way, there is no "progress" that I can see that I could establish a hook into, anyway.
What does -getLociWithChromsomes: do? What happens when you drill into that method in Instruments to see what is taking all the time?
Same question with -GetAllLoci: and -getMaxLocusSnps?
It appears from the small amount of data that I can see is that you are doing a ton of fetching on launch. That is a bad design no matter what platform you are on. You should avoid doing a lot of fetching during the launch of the document and delay it until after the initial document/application launch has completed.
You could use a multi-threaded design here and it probably would help but it is really masking the problem.
The core of the issue appears to be that you are trying to do too much on launch. I am not certain that the entire delay is in core data or what you are doing with the data once it is retrieved as I do not have code level access through the trace you provided. It would be interesting to see screenshots of those methods above in Instruments with the time percentages highlighted.
Update
Again, you are loading too much during launch and blocking the UI. You have three answers all saying the same basic thing. This is not a Core Data problem. This is a performance problem because you are loading too much on launch or you are doing too heavy of a calculation on launch.
In addition to the specific hints Duncan gave you it's always useful to check out the latest (and free) WWDC videos on ADC to get an idea on the patterns provided by OS X and Cocoa in particular to boost an apps performance. Some starting points:
WWDC '12
- Asynchronous Design Patterns with Blocks, GCD, and XPC
WWDC '13
- Designing Code for Performance
Try opening the store on a background thread and once it's open activate the UI - that seems to work OK.
I create a background thread to call the [psc addPersistentStoreWithType:configuration:URL:options:error:] and once that's complete I hand control back to the main thread where the managedObjectContext gets created and the UI enabled.
You face this issue if Core Data has to do a big upgrade to a new model version as well. Some of my files take around a minute and if they are in iCloud it can be even longer. And if the upgrade happens on an iOS device then it can take a few minutes so this seems to be important for iOS apps as well.
BTW I have posted sample apps here
http://ossh.com.au/design-and-technology/software-development/sample-library-style-ios-core-data-app-with-icloud-integration/
I have a AngularJS application that makes use of web services to load the content and render the view. I've checked the performance of application on Chrome and it is running fast enough. However on IE 8, I'm facing huge performance issues.
Noticed the memory usage for Internet Explorer. Found that it was around 200MB. If I opened multiple instances of the application in separate tabs, the memory usage kept on doubling with each instance. This is slowing down the response time and in the effect the whole PC performance. No such issues are there on Chrome.
I feel that it is because of the data that is present in the model for the application. So with each tab on IE, the model data is doubled and the RAM usage also increases. However, this problem doesn't occur for me in Chrome.
Please suggest some performance optimization techniques that I can use.
Try to avoid the use of "ng-repeat" for a large list rendering. Or, you can use the infinite scrolling for the same.
So, I've done a bit of reading around the forums about AssetBundles and the Resources folder in Unity 3D, and I can't figure out the optimal solution for the problem I'm facing. Here's the problem:
I've got a program designed for standalone, that loads "books" full of .png and .jpg images. The pages are, at the moment, the same every time the program starts. At the start of the scene for any "book", it's loading all those images at once using www.texture and a path. I'm realizing now, however, that this is possibly an non-performant method for accessing things at runtime -- it's slow! Which means the user can't do anything for 5-20 seconds while the scene starts and the book's page images load up (on non-legendary computers). SO, I can't figure out which of the three things would be the fastest:
1) Loading one asset bundle per book (say 20 textures # 1 mb each).
2) Loading one asset bundle per page (1 mb each).
3) Either of the first two options, but loaded from the resources folder.
Which one would be faster, and why? I understand that asset bundles are packaged by unity, but does this mean that the textures inside will be pre-compressed and easier on memory at load time? Does the resources folder cause less load time? What gives? As I understand it, the resources folder loads into a cache -- but is it the same cache that the standalone player uses normally? Or is this extra, unused space? I guess another issue is that I'm not sure what the difference is between loading things from memory and storing them in the cache.
Cheers, folks...
The Resource folders are bundled managed assets. That means they will be compressed by Unity, following the settings you apply in the IDE. They are therefore efficient to load at runtime. You can tailor the compression for each platform, which should further optimize performance.
We make expensive use of Resources.Load() to pull assets and it performs well on both desktop and mobile.
There is also a special folder, called StreamingAssets, that you can use to put bundled un-managed assets. This is where we put the videos we want to play at runtime, but don't want Unity to convert them to the default ogg codec. On mobile these play in the native video player. You can also put images in there and loading them is like using WWW class. Slow, because Unity needs to sanitize and compress the images at load time.
Loading WWW is slower due to the overhead of processing asset, as mentioned above. But you can pull data from a server or from outside the application "sandbox".
Only load what you need to display and implement a background process to fetch additional content when the user is busy going through the first pages of each book. This would avoid blocking the UI too long.
Optimize the images to reduce the file size. Use tinypng, if you need transparent images, or stick to compressed JPGs
Try using Power of 2 images where possible. This should speed up the runtime processing a little.
ath.
Great answer from Jerome about Resources. To add some additional info for future searches regarding AssetBundles, here are two scenarios:
Your game is too big
You have a ton of textures, say, and your iOS game is above 100 mb -- meaning Apple will show a warning to users and prevent them from downloading over cellular. Resources won't help because everything in that folder is bundled with the app.
Solution: Move the artwork you don't absolutely need on first-run into asset bundles. Build the bundles, upload them to a server somewhere, then download them at runtime as needed. Now your game is much smaller and won't have any scary warnings.
You need different versions of artwork for different platforms
Alternative scenario: you're developing for iPhone and iPad. For the same reasons as above you shrink your artwork as much as possible to hit the 100 mb limit for iPhone. But now the game looks terrible on iPad. What do?
Solution: You create an asset bundle with two variants. One for phones with low res artwork, and one for tablets with high res artwork. In this case the asset bundles can be shipped with the game or sent to a server. At run-time you pick the correct variant and load from the asset bundle, getting the appropriate artwork without having to if/else everywhere.
With all that being said, asset bundles are more complicated to use, poorly documented, and Unity's demos don't work properly at times. So seriously evaluate whether you need them.
I need to generate an imaged based on data returned from a WebService call within a PeriodicTask in a Windows Phone app (Mango+).
I've seen a few ways of doing it in the main app but nothing that seems to work from a Scheduled Task
It depends. If you're in a background agent, memory is precious. The libraries you load count against your allocation limit, too, so you have less than the advertised amount.
Do you have a base image that you're modifying? If so, avoid creating UI elements and try to work with a WriteableBitmap. There is a library (yes, memory, but it's incredibly useful) that provides useful methods for working with such images called WriteableBitmapEx.
If you're generating simple images from scratch, going the UserControl route is workable too.
Try this guide I've described on my blog:
http://suchan.cz/?p=110
Basically you have to create your own UserControl and then render it into image and save it either as jpg, without transparency, or as transparent png. Also make sure you use as low memory as you can in the Backgroud Agent, if you use more than 6MB in WP7 or 11MB in WP8, your periodic task will be killed without notice.
I use a utility called ImageTools to render a PNG from a user control (note, this is not my blog). I created a shared library, with references to ImageTools, ImageTools.IO.Png, and ImageTools.Utils. The shared library does all the heavy lifting. Then my background agent project references the shared library project, and in the ScheduledAgent.OnInvoke it calls into the shared library to do the work. I am on Windows Phone 8 but it seems to work very well.
My application has several large forms with lots of images which dramatically increases the size of the built executable. Over time, it seems that the startup performance becomes sluggish and it doesn't seem to be getting any better.
If I put all of the forms besides the main form in a separate dll, would it alleviate some of the pressure put on the application during startup?
I'd test it myself, but I have A LOT of forms and I don't want to do it unless someone can confirm that such an action will prove to be useful.
Many factors can affect startup performance. Have you used any tools to prove that it's the images?
For a start, go through these tips:
http://devcomponents.com/blog/?p=361
And consider using multithreading to load bigger objects in the background.
I'm not quite sure about that, but if I were you I would use the Profiler when it comes to improving performance.
Before I go guessing what's wrong, I consult with it and work my way up, because it tells me which methods and classes are costing the most in my code.
Another tip that may be useful: This reduced my application's startup time from 2 minutes to <10 seconds on a low-end thin client. Use NGEN to generate a precompiled native image of your assemblies.
I'm wondering if you were to use MEF and Lazy load, then when you actually need the module (Form) instantiate by calling .Value.
There are a couple of things I do with applications containing a lot of forms:
Create a UI .exe: basically only my forms
Create a backend .dll: everything that does the work behind the UI.
Are the images actually included in the .dll? If so, I would actually put my images into a .dll separate from the UI.
Given that the images are for toolbars, I wouldn't split them out as resources. I'll still stand fast on my advice to split into multiple .dlls.
As others said, profile, don't guess.
Not just any profiler will do.
Here's a user (besides me) who discovered random pausing on his own.
You say the "intense" methods are all in dlls you don't have source code for - that's typical and normal.
What you need to know is which statements in your code are requesting the time to be spent, and they can't be restricted to CPU-only time.
Most profilers don't tell you this, but random-pausing does.
If you're interested, here's a recent discussion of the issues.