New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
experiment with android:largeHeap=true in manifest #99
Comments
Hey, I wasn't aware of that manifest option, thanks for letting me know!
|
Thanks to @pmoor for pointing out the availability of this manifest attribute, reporting issue #99! Large objects are streamed wherever possible and consequently files of this size often won't cause problems, even on a relatively memory constrained device like an Android. That works so long as the large object is stored as a whole object within the Git packfile. However, if the file is similar to any other file stored anywhere within the repositories history, they can both be stored in delta format - which unfortunately requires a full in-memory representation to decompress. https://github.com/rtyley/agit/wiki/Memory
Yay! Thanks for the build! I was able to clone my repo on the Moto X! |
Brilliant! That's good to know - thanks again for pointing out the option 👍 |
According to http://developer.android.com/guide/topics/manifest/application-element.html this may help with memory pressure:
android:largeHeap
Whether your application's processes should be created with a large Dalvik heap. This applies to all processes created for the application. It only applies to the first application loaded into a process; if you're using a shared user ID to allow multiple applications to use a process, they all must use this option consistently or they will have unpredictable results.
Most apps should not need this and should instead focus on reducing their overall memory usage for improved performance. Enabling this also does not guarantee a fixed increase in available memory, because some devices are constrained by their total available memory.
To query the available memory size at runtime, use the methods getMemoryClass() or getLargeMemoryClass().
I have a repository I consistently fail to clone on most of my devices (only works on the N4). I know I shouldn't have large files in it, but it's just very convenient ;-) Would be awesome if you could give largeHeap a try to see if it improves things.
thank you,
patrick
The text was updated successfully, but these errors were encountered: