Re: DataInputStream
Robert Klemme wrote:
Lew wrote:
Robert Klemme wrote:
bob wrote:
The issue is that it's too slow.
How slow is that, and how fast should it be?
How much faster could it be, and what makes you think that's possible?
Ah, now we're getting closer to the point. I'd first test whether=
the
slowness is caused by the underlying stream or the reading procedure.
If it's the stream (e.g. because you read unbuffered from a socket)
then you might want to add buffering or you need a faster NIC. If
it's in the reading then look at Mark's suggestion.
The OS could also be a factor. So could other loads on the system,=
particularly the I/O subsystem. Given that we don't know what speed =
is "too slow" and what speed is acceptable, nor the system configuration, n=
or the load profile, nor anything else, there's nothing we can say to affec=
t the "too slow" evaluation.
Absolutely. I just wanted to partition the problem space in "float
reading and parsing" and "general IO" because that information is
needed to decide whether the approach to reading floats is wrong
because it's too slow. OS then falls into "general IO".
If "general IO" takes 100 ms and the specifics of the float conversion take=
100 =CE=BCs (to pick numbers out of my, er, hat), then time spent on the l=
atter should wait until the former is properly handled. You might shave a =
whopping 50 =CE=BCs out of your 100100 =CE=BCs total overhad if you double =
the speed of the wrong side. You'll still have roughly 99.95% of your over=
head.
It's not enough to solve the problem; you have to solve the right problem.
That said, the partition is useful. It helps you organize your search for =
the high-value targets.
What I'm hoping for is something like this:
=
byte[] b = new byte[numfloats*4];
Did you indent enough there?
dis.read(b, 0, numfloats*4);
float[] f = (float[]) b;
return f;
I don't know why, but it won't let me do the cast. Any ideas?
See Patricia's reply. Java works fundamentally different from C o=
r C+
+. For example, there are no pointers into memory. I seriou=
sly
Well, there are, actually.
I can see why you say that (because eventually every reference of any
kind points to a place in memory). But for the sake of this
discussion and the general concept of Java I'd rather stick with "no
pointers into memory in Java" because that makes it crystal clear that
there is not that free access to memory cells as in C/C++. Actually
I'd rather stick with the truth to make it crystal clear what's true.
Imprecise analysis leads to incorrect solutions.
The truth is that Java has pointers. The nuance is that these pointers do =
not behave like those in C, but then C didn't invent pointers to begin with=
..
objects can even move in memory so an unchanged reference can point to
different locations throughout its lifetime, while an unchanged C
pointer always references the same memory addresses.
So say that, rather than the imprecise and incorrect canard that "Java does=
n't have pointers".
In the case of the OP's code, they're 'b' and 'f'. However, =
the pointers in Java are rigidly typed, unlike those in C, so you cannot ca=
st a pointer to 'byte[]' into a pointer to 'float[]'.
That's why I prefer the term "object reference" which is also what the
JLS uses (even though there are some occurrences of "pointer" and we
have "NullPointerException").
The JLS flat out defines the terms "pointer" and "reference" as equivalent.
The word "object" in "object reference" is redundant, and not correct in th=
e case when the reference points (!) to 'null'.
But do feel free to use the term "reference", which in Java's nomenclature =
is exactly equivalent to "pointer".
The key feature of a pointer is that it points to something. The ability t=
o alias pointer types (e.g., 'byte' array to 'float' array), perform pointe=
r arithmetic or to point to invalid memory are not essential to the definit=
ion of "pointer".
Let's not lie to people in an attempt to dumb the information down. Let's =
instead tell the truth and require programmers to be smart. There's far to=
o much dumb programming in the wild already.
--
Lew