File IO performance on SD card - android

all
When I try to read some media file from sd card after the first time I insert to the device, the read performance is much worse than the second time, does anybody have any idea about this phenomena, and how can I avoid this problem, I tried open and fopen, but the results are the same, I just want read performance is the same, no matter when I insert SD card, thanks

Using O_DIRECT (see open(2)) when opening the file will bypass the buffer cache. This is often not a good idea, but I would expect it to be more consistent from run to run.
Keep in mind that using O_DIRECT requires that the memory read into be SC_PAGESIZE aligned and read in blocks which are multiples of SC_PAGESIZE.

Are you saying it's worse for the first read than subsequent reads before you remove the device? If so, this is normal - it's due to buffering. Basically the system is using the system RAM to speed up the perceived speed of the device.
If you remove the card after unmounting it and then put it back and remount it I would expect the first read would again be slower, then subsequent reads would appear to be faster again.

Related

LOST.DIR problems with flash drive

I'll try to sum this up briefly. I have an app that can synchronize its data with a USB flash drive connected via an OTG adapter. The problem is this: some files will end up in a folder called LOST.DIR in the root of the flash drive. They are all exactly 4KB large and have random, 3-number names with no file extension. I know they contain data from my app because if I open them in notepad, I can see the data that my app is outputting. This data, however, is sometimes mixed with random symbols. Based on my rudimentary knowledge of file systems, the consistent size of the files and random content makes me think these are blocks of memory marked bad by Android and moved to this folder.
There is one caveat: I am treating the flash drives as if they are hot-swappable, as they would be on a Windows device. I understand that it may not be valid to think of them as this. To get around this, I'm calling running the sync command via su after I finish reading and writing to and from the flash drive. My understanding is that this should sync the in-RAM buffer/cache with the physical flash drive, thereby making it safe to remove. This may be a faulty assumption.
So, my question is two-fold:
What is causing data to randomly disappear and be moved to LOST.DIR?
Is it safe to be treating flash drives as hot swappable? If not, is there a way to make them behave that way?
If my question is not clear enough or you need more information, I can clarify things for you. Thank you.
What comes to mind is that you are not the only one accessing the flash drive (media scanner, for instance), so sync will flush buffers but something could be ongoing, and sync exits anyway. I think you should also unmount it (and it will fail until it's really safe to remove).

Which is faster to access a file in android, sdcard or system partition?

I have one simple question. If i have one file in system partition of android and if i copy the same file on sdcard, which will be faster to access?
Please answer this question.
Thanks in advance
The difference will be negligible. In any case, most newer devices have just one storage onboard the device, which is partitioned. In such devices, the need to access a separate SD Card goes away, as the memory is the same as the system storage.
On devices with an SD Card, there may be a very minute delay in accessing the file, but it will be negligible in pretty much any scenario.
You will not be able to really notice the access speed difference between accessing file from internal memory and SD Card.
With internal memory you will get added advantage of a security as it won't be accessible for other applications or you cannot access it by mounting.
The answer is Internal phone memory
because disk management(for phone ) is always better for internal memory as compared to SD card, So it is faster to access internal memory but you will not be able to notice the because difference is in mili seconds
With internal memory you will get advantage like user can't see your file until unless device is not rooted.
As stated, the time difference is not noticeable. However, a simple law of physics (and EE) will tell you that the longer the distance is (in this case the I/O bus), the longer it will take in time. Thus, the SDCard is slower than anything on the motherboard, even though it is measured in miliseconds.
I have found the SDCard is best used for static storage of your media files, and apps should be installed on the phone making them run as fast as possible, even though you can move some apps to the SDCard.
The speed is not noticeable unless you are coping the very large video files. The SD card speed is measured by class like:(Class 4, 6 or 10), the class 10 have higher speed as 10MB/S and class 2 have speed around 2MB/S. So, for good class of SD card, the speed gap is less. However, normally phone memory is faster than the SD card.

How can I write data from an Android's sensors to a document that I can access later?

So I'm creating a project on an Android Galaxy Tab 10.1 that uses its accelerometers and gyroscopes. One of the steps here is to collect alot of data and determine its accuracy and drift. To do this I need to move the device and allow the sensors to get their readings, and then take those readings and put them through some analysis.
My admittedly primitive way of doing this is to send each reading as an error to the log, copy the log from Eclipse, paste it in notepad, and format it, getting rid of other unwanted errors and timestamps. This method is not very good, and the log in Eclipse deletes the old log entries if the list gets too long, meaning I can only look at about 30 seconds of data.
I need much more time than this so I thought of a couple ways to fix the issue:
If I could somehow write the readings directly from the Android to a document on the computer im using, that would solve all my problems.
If i could write the readings to a file on the Android that could be saved and later transfered to the computer, that would also work
Writing a file to the internal SD card is quite easy and would probably solve your second point. You can access the file later via USB, which just mounts the internal SD card like an USB thumb drive.
For example, this question and answer gives you some starting points.

Drawables natively leak memory?

I'm reading this question because I have to load a ton of downloaded resources into an app I'm writing, and was curious if there was a dramatic performance hit in doing so [vs. having them in the .apk], and the "correct" answer to the question implies that while there is no performance degradation, you have to worry about releasing the memory back when you're done with it, lest it leak.
Can anyone confidently confirm or deny this? My impression was that a loaded Drawable was GCed just like everything else when the Activity it was cleaned up. I'd very much like to know if that's not true, and what the most reliable way to manually collect the memory in said instance is.
Also, does anyone know if there's a noticeable performance hit in loading images from the SDCard, vs. from the phone's memory. I'm not an electrical engineer, so, intuitively, it seems like since this is all solid state memory, it should all get read at about the same pace, but I'd love to get a definitive answer.
Quick answer:
Bitmaps take two passes of the garbage collector to clean up. The first pass releases the Java object, the second pass the native pixel data. They don't leak, but you can run out of memory between when you null the pointers and the GC hits its second pass over them. This is true no matter what resource they come from. It's always a good idea to call recycle() on a bit map when you're sure both you, and the system, are done with them.
Gingerbread is particularly bad in dealing with out of memory issues and bitmaps due to a bug in the Dalvik VM.
In my experience, loading images out of the apk is MUCH faster than off the SD card.
1) They're zip aligned in the apk (if you align your apk, which you should)
2) Different phones have different access times to the SD card. The general rule is, if it's on the sd card, it's going to load SLOWLY. You can get away with loading drawables from the internal memory on the main thread (even though it's a bad idea). You cannot load anything from the SD card on the main thread. Ever :-\
If I were you, I'd be as lazy as possible when loading images, I'd keep them in the apk if possible.

Effect of frequent sdcard writes

In my chat app, I am adding the ability to log chats. The logs are saved on the sdcard and one BufferedWriter is kept open for every person/channel chat is done with. I'm wondering what effects this might have have on the sdcard and its life.
My BufferedWriter's buffer size is to 1024, I'm also wondering if that is too small or too big.
Flash memory cards have an endurance of about a million write cycles per area and probably include wear levelling which basically means trying to write to different areas so specific spots dont wear out.
So after about (sizeOfSDCard/sizeOfYourData)*1,000,000 writes, you will have ruined their card.
Practically, this means you probably aren't going to cause any harm.

Categories

Resources