Firstly, I can't help but wonder why you need all of the characters in
memory at once. On a constrained device I'd rather stream the
characters and process them that way. What do you plan to do with
this data that requires it all be in memory at once? However, if you
truly need to, then tell me how long these two pieces of code take on
your device:
long startTime = System.currentTimeMillis();
FileInputStream fis = new FileInputStream("some large file");
FileChannel fc = fis.getChannel();
ByteBuffer bb = ByteBuffer.allocateDirect(fis.available());
CharBuffer cc = bb.asCharBuffer();
int numberOfBytesRead = fc.read(bb);
char c[] = new char[cc.limit()];
cc.get(c);
System.out.println(c[c.length - 1]);
System.out.println((System.currentTimeMillis() - startTime));
And:
long startTime = System.currentTimeMillis();
FileInputStream fis = new FileInputStream("some large file");
FileChannel fc = fis.getChannel();
ByteBuffer bb = ByteBuffer.allocateDirect(fis.available());
ShortBuffer cc = bb.asShortBuffer();
int numberOfBytesRead = fc.read(bb);
short s[] = new short[cc.limit()];
cc.get(s);
System.out.println(c[c.length - 1]);
System.out.println((System.currentTimeMillis() - startTime));
The "direct" in the allocate should make the first part fast in both
cases, but it is the character decoding (see CharsetDecoder) that is
costing you the most in the first example; that why the ShortBuffer is
so much faster in general. Do you really care that they are
characters, or is it just that they are sixteen bits?
Regards
Timothy
On Sep 2, 12:44 pm, WoodManEXP <[email protected]> wrote:
> Hi Haravikk,
>
> Thanks for the suggestion and on fist glance it looks like this ought
> to work, but no such luck :-(
>
> The InputStreamReader has two things going against it for large array
> operations.
>
> 1. It allocates a huge buffer (way larger than the 8K advertised).
> Whenever it tried it to read 200,000 chars the LogCat shows "...
> dvmMalloc(24960292/0x017cdd24): someone's allocating a huge buffer" It
> is trying to allocate a 24mB buffer ???
>
> 2. It wants to process the byte[] array character by character byte by
> byte with a CharsetDecoder object which makes it a painfully slow
> operation.
>
> I'm gona keep plugging away at the JNI/NDK option.
>
> Thank you!
>
> On Sep 2, 9:02 am, Haravikk <[email protected]> wrote:
>
>
>
> > Can't you just use an InputStreamReader wrapping around your
> > InputStream? Like so:
>
> > char[] cBuffer = new char[1000000];
> > InputStreamReader reader = new InputStreamReader(dInStream);
> > numBytesRead = reader.read(cBuffer);
>
> > The problem with ByteBuffers is that they are only meant to hold data
> > temporarily, and it sounds like you'd be reading a large byte array
> > in, then converting to a large char-array which isn't pretty.
>
> > On Sep 2, 12:18 pm,WoodManEXP<[email protected]> wrote:
>
> > > Hi Dmitry,
>
> > > Thank you for responding. The chars I’d like to read are two byte
> > > chars (they really are an array of ushorts, but the java char type
> > > represents them OK).
>
> > > As far as I can tell there is simply no way in Java to implement a
> > > seemingly obvious sequence of statements like:
>
> > > char[] cBuffer = new char[1000000];
> > > numBytesRead = dInStream.read(cBuffer);
>
> > > The java.io classes will read only byte[] arrays or will read only one
> > > char element at the time (painfully slow). The facilities for
> > > converting the byte[] array to any other data types (java.nio stuff)
> > > are painfully slow as well.
>
> > > One suggestion has been to use JNI (NDK in Android lingo). Jeeze, what
> > > a convoluted mess that is… But I’m going to look into it to write a
> > > native function to do the read or maybe cast a short[] to a byte[] to
> > > fool the java.io read method.
>
> > > If anyone can share any ideas that will be great.
>
> > > Thanks!- Hide quoted text -
>
> > - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
