I have 9000 files in the memory card, I have created an application that read each file and parse it in to a String and put that String in a HashMap in order to avoid repetition,and save the names of only unrepeated files, but that operation is taking about 7 to 10 seconds.. is there any way to make that faster.. I tried to find better method but I didn't find anything...
Object : get the names and Strings of all the unrepeated files..
Is there any way to do that faster using java, new IO, or NDK, is it worth to install NDK and try that using C language and pointers..
I appreciate any help..
Its obviously that even just loading of 9k files takes some time. Imagine there a lot of android devices and there are many devices which are not as fast as device which you are using to test. So the operation gonna take even more time on such devices. The problem is a numerous of small files. Maybe you should pack it in one, lets say a JSON or XML? Reading of 1 file is more faster and reliable.
Related
For the past six months as my final university project, I've been writing a PlayStation 1 emulator in Java to prove it can be performant - part of my strategy involves writing a custom class loader that imports bytecode I have just generated from an array into a new class - in effect a Java bytecode dynarec core which speeds up the emulated CPU orders of magnitude (in theory). All quite possible on an Oracle JVM, and done before by others.
My question is, aside from the fact I would need to generate dalvik bytecode rather than Java bytecode, there doesn't seem to be anyway to dynamically load classes into a running Android app that doesn't involve loading them from a dex file on flash somewhere. I know similar things have been asked before, but as I would eventually like to port this emulator (and have it be quicker than its currently unplayable speed), is there anyway around this? I don't want to be continually writing to flash when a new section of MIPS code is converted to bytecode, as it could wear the flash out and probably isn't very fast either.
A thought I had was maybe mounting a tmpfs using a small JNI lib and storing class files there to be loaded, so in effect storing them in RAM as before - is this even possible for an unprivileged app to do though? I'd appreciate peoples input/thoughts.
No, that might be possible on a jailbroken device but it's not possible in a sandboxed app.
I tried several ways to load dynamic code on Android but the only feasible way is via the DexClassLoader where the dex file must be stored in a privileged region.
You can have a look at my project Byte Buddy where I implemented such class loading: https://github.com/raphw/byte-buddy/blob/master/byte-buddy-android/src/main/java/net/bytebuddy/android/AndroidClassLoadingStrategy.java
I am using docx4j library to create/open/edit docx file. But it takes around 30 seconds to initialize this line
wordMLPackage = (WordprocessingMLPackage)loader.get(file);
It takes same time either it simple document(may be empty or single word/line file) or complex document with images and tables.
I have increased memory for eclipse in eclipse.ini and VMHeap for emulator but no effect .It is slow on emulator as well as on real device. Please help!
See forum post wordprocessingmlpackage-load-file-is-extremely-slow
The JAXB context init time is unavoidable (unless you remove some of the packages listed, or hack your JAXB implementation to do some funky on demand type loading), but only needs to be done once.
I have couple of initialization classes that do nothing else but to fill initial unchanged data structures. In total about 200k lines in 5 data Classes just doing things like:
x = new Y(13);
xTmp.z.add(x);
allElements.add("just some text");
So basically initializing arrays of my structures - these are all basically "constants".
I was wondering how to best structure the project, for example using libraries or doing anything else so the development of the project can be handled more efficiently than to always compile, link and load the large data classes to the device for testing.
Forunately Eclipse is real fast and compiling takes not more than 1 minute (compared to xCode where it takes over 1,5 hours to compile). However, I am sure the experts with experience of writing large projects have thir tips and tricks how to best get their hands around it.
Many thanks!
I wouldn't hard code all that data at all.
Define a file format for all that data, and build a simple parser for it (or better yet, use an existing structured file format and drive from that). There is no reason to have to rebuild your code when you change the initial data.
Bundle those initialization files with your application (you can even put the inside your jar files and access them as resources).
I'm porting a rather large game engine written in C++ from Windows/Mac to Android. There is a lot of pre-existing code to read assets for games. In addition, there is quite a bit of code doing file system calls (stat'ing the files to make sure they exist, looking up all of the files and directories inside of a directory, etc.)
Right now, I'm focusing on just getting something up and running as quickly as possible, so I'd prefer not to have to rewrite a lot of this. What would be a good way of getting our game assets onto the device and accessing them with minimal changes to our existing standard C++ file system API usage?
I've got some basic support implemented already using the Asset Manager API, but that doesn't support the file system calls and I'm concerned that the 1 MB asset size limit is going to bite me at some point.
I've also looked at OBB, but the tools for creating an OBB file don't look like they are part of the current SDK/NDK. Otherwise, that looks like it would be perfect.
Is it a horrible idea to package up all of the files and just extract them on the SD Card the first time the app is run? Or is there some better way of dealing with this?
Update: I'm also not very concerned on being able to run on a broad range of devices, I am specifically looking at newish tablets, probably the 10.1" Samsung Galaxy tab.
We ran into a similar problem in developing our (data-file-heavy) app, and we ended up deciding to keep the APK tiny and simply download our data files on first run; they're going to have to be downloaded either way, but a small APK works much better on older devices without a lot of internal storage. Plus, you can potentially rig up a way for people to copy over the files directly from their computer if they have a limited data plan or a slow internet connection on their phone.
The "Downloader" sample app in apps-for-android (confusingly buried under "Samples") is almost a fully-implemented solution for this - you can pretty much just plug in the particulars of your data files and let it do the rest.
I wrote an app that relies on putting a good amount of native code into the Android filesystem. I did this by packaging the files into the APK as 'resources'. Instead of pushing them to the SD card, you can put then into the application's private namespace, I.E. /data/data/com.yourdomain.yourapp/nativeFolder.
For details on how to accomplish this, you can see my answer to this question.
It's fairly simple to package to just unpack them on the first run and never worry about them again. Also, since they're under the application's namespace, they should be deleted if/when someone were to decide to delete your app.
EDIT:
This method can be used to put anything into the app's private area; /data/data/com.yourdomain.yourapp/
However, as far as I know, your application has to be the one to create all the folders and sub-folders in this area. Luckily this is fairly easy to do. For example to have your app make a folder:
Process mkdir = Runtime.getRuntime().exec("mkdir " +localPath);
That works as it would in most linux shells. I walked through the assets folder I packaged into my APK, made the corresponding directories and copied all the native files to those directories.
What you might be more concerned with is the limited Android shell. There are many commands that you might want that aren't present. stat for example isn't available, so all of this may be moot if your native code can't make it's system calls.
I'm parsing a big XML file using SAXParser in Android and was wondering if there's a faster way of doing string comparisons? I've heard rumours that you can use the Dalvik VM to do something which will save memory allocated and hence speed it all up, but I can't find anything online.
Can anyone point me in the right direction to either use Dalvik to speed up my parsing or a better, faster way of doing XML parsing?
String's compareTo() method is implemented internally in dalvik as a special hand-crafted assembly routine. It's unlikely you'll be able to beat its performance for string comparisons
If this is an xml file that you are downloading, I don't know of any way to speed up your parsing time. However, if you can include it in the apk as a resource (in the res/xml folder), then it will be compiled into Android's binary xml format when you build the apk, and you can access it via XmlResourceParser, which should be significantly faster
I would use the goold old String.compareTo(String).
A faster way may exist right now, but compareTo() is the standard way, and is therefore the only that will benefit of future optimizations made by Android. So at the end an optimized comparison may become slower than the standard way to do.
This is quite similar to the member fields access time. At the beginning of Android it was way faster to do
final AnyClass local = mMyMember;
local.something();
than
mMyMember.something();
But this is no longer the case.