Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
So I learned recently that the standard basic networking in Java goes like this:
out = new PrintWriter(echoSocket.getOutputStream(), true);
in = new BufferedReader(new InputStreamReader(echoSocket.getInputStream()));
I just want to clarify, so for the output we don't use a BufferedWriter because that's the job on the server's side? Would it be wrong to do something like this:
out = new BufferedWriter(PrintWriter(echoSocket.getOutputStream(), true));
From the Java documentation:
http://docs.oracle.com/javase/tutorial/essential/io/buffers.html
Most of the examples we've seen so far use unbuffered I/O. This means each read or write request is handled directly by the
underlying OS. This can make a program much less efficient, since each
such request often triggers disk access, network activity, or some
other operation that is relatively expensive.
To reduce this kind of overhead, the Java platform implements buffered I/O streams. Buffered input streams read data from a memory
area known as a buffer; the native input API is called only when the
buffer is empty. Similarly, buffered output streams write data to a
buffer, and the native output API is called only when the buffer is
full.
Yes, "buffered" input AND output is usually a Good Idea.
IMHO...
PS:
I don't see anything wrong with PrintWriter. Especially if I wanted to do "printf()" style text I/O directly to the socket.
I wouldn't call that example "standard". It's a simple tutorial. It uses BufferedReader not for buffering, but for the BufferedReader.readLine() method.
For a serious application, yes, the output should be buffered. You should not write many pieces of small data. If nothing else, the overhead of system call for each write() is a killer.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I was told by a couple of my professors that that Java Scanner class is meant to be a simple learning tool, but that there are more professional ways to read inputs. Is this true? If so, can one give examples?
As you mention the Java Scanner class in a context of learning, I assume you are talking about reading the user's input from console.
I don't know if the Scanner class was created with learning purposes but certainly there are better ways of reading input from the console.
The scanner class may suit you in a normal scenario but if for example you need to read a really fast or irregular input synchronized perfectly with some events on the program then it might give you some problems. For example the BufferedReader class would be the best solution here.
You can read about the "topic" here.
A Buffer basically allows you to receive information at "any" speed and retrieve it in a constant flux. The easiest example of buffering is Youtube:
You are downloading the content of a video through internet, and the internet speed is not always constant. As this happens, if you reproduce "directly" what you are downloading then the video might reproduce x2 times faster or get stuck and pause for half a second, etc...
The solution to this is a buffer where you store all the data you download from the Youtube server and then process it at a constant speed so your video reproduces as it was intended to.
I hope the explanation was clear and helpful, I am still improving my english!
You Can Use
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String str1 = br.readLine();
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
Currently I am working on transfer image from C++ to Java.
The destination location is allocate by Java,
the source location is the image generated by C++, so.
I have a
uint8_t* pixelPtr
, I want to move the content of this to a
__uint8_t* data
without copy.
I have 1920*1080*3 bytes in total, so I want to move rather than copy to be fast in computation, I am wondering is there any trick way to do so?
Thank you in advance!
Let's recap:
The source is a buffer allocated in C++ by an image generation function.
The destination is a buffer allocated in Java by some other code somewhere.
You want to transfer data between the two buffers.
As long as those two buffers are distinct, there is no "trick" to avoid this. "Moving" in this context would mean swapping the pointers around, but that does nothing to the underlying buffers. You will just have to copy the data.
Explore solutions such as generating the data in the destination buffer in the first place, or making use of appropriate functionality exposed by the C++ image generation function (or the Java code). Unfortunately we can't speculate on the possible existence or form of such solutions, from here.
The standard way is, you should modify your C++ code so it creates the data not wherever it wants, but in the given place. That is, if you have code like this
uint8_t* GenerateImage(...parameters...)
{
uint8_t* output = ... allocate ...
return output;
}
you should change it to receive the destination as a parameter
void GenerateImage(...parameters..., __uint8_t* destination)
{
... fill the destination ...
}
The latter is better C++ design anyway - this way you don't need to make a separate DestroyImage function - the memory is managed entirely by Java.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I realize that writes are slower in general. But I want to know by how much.
I have some code, in server class, that writes to a log file:
if (inputLine.equals("y")){
System.out.println("\nThe input was Yes!\n");
newPosition++;
logPosition();
}
The problem is that, on the other side in my client class I am running through an array pretty quickly. It is a regular for-loop :
for (int i=0; i<KKJokes.length; i++) {
out.println(KKJokes[i%KKJokes.length]);
}
Variable out is for the socket (out = new PrintWriter(kkSocket.getOutputStream(), true);).
I want to know a way to slow down the Client sending to the server (via array). So that it can only start outputting again once we finished writing to the log file.
Also if anyone wants to see, full Client code & full Server code.
You can't rely on timing for this. You will have to have the server send an acknowledgement of every message, which the client must read before it sends again.
Normally the server would accept in a loop and let the the socket processing be handled in another thread from a thread pool. Then it could "throttle" accepting (=wait a bit when very busy) when to many requests come in.
Also use a real logger. Besides more functionality like rotating logs, they are built for speed too.
Furthermore use a specified character encoding, so not to be surprised if client and server operate with another encoding:
new InputStreamReader(inputStream, "UTF-8")
Consider using the Java's Thread.Sleep() function to temporarily pause execution of the running thread. So your code might look something like this,
for (int i = 0; i < KKJokes.length; i++ ) {
out.println(KKJokes[ i % KKJokes.length ]);
Thread.sleep(2000); // Time in milliseconds
}
See the docs for more details.
Hope this helps.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I always get confused when to process my input data how, which process. Different times i find different solutions. I am also not clear about their Hierarchy.
InputStream is parent class of all input streams and readers. Classes that have Stream keyword will work with bytes whereas classes which have Reader keyword will work with characters.
Buffer is wrapper around these streams to decrease the system calls and increase performance and speed of reading. Non buffered streams return single byte each time whereas Bufferd stream will not return until the buffer gets full. For example if you take BufferedReader you can read a whole line using readLine() but in non buffered stream you must read single character using read() method.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I was making a file-transfer program and it takes forever to transmit this 800kb test picture I made. Clearly I don't want to spend 30 minutes for every mb of data, so I was curious if there was any way to speed up my code or Java in general. I had heard about allocating extra RAM, but never looked into it.
If anyone can find a better algorithm for my code that would be appreciated, otherwise I may have to step to C++ or C and try again.
Server code block:
if(file.exists()){
for(long l=0;l<file.length();l++){
out.writeByte(fIS.read());
}
}
where fIS is the FileInputStream and out is the outgoing DataOutputStream. The rest of the code is basically sending lengths and a flag, but I can add if requested.
Client Code:
b = new byte[len];
for(int x=0;x<len;x++){
b[x] = dIS.readByte();
}
fOS.write(b);
where len is the read length of the file expected from the Server, b is the array of bytes that make up the file, dIS is the input stream from the server, and fOS is the FileOutputStream.
I also just attempted using Readers and readLine() with writeChars() and readChar(), but this seems to equate to about the same thing.
Reading a file a byte at a time and sending over the network one byte at a time is going to be slow in any language :)
Consider using a BufferedInputStream for reading and BufferedOutputStream for writing.