Why https connections are so slow when debugging (stepping over) in Java?
up vote
0
down vote
favorite
I'm trying to debug some problems with my Java code, which establishes a http/https connection. I'm wondering why the connection gets ridiculously slow (more than one minute for downloading a small web page) when debugging, even when stepping-over the method which does the network work. And if there is some remedy.
Below I post an example (you can change https:
to http:
, and try debugging this from Eclipse pressing F11
- for stepping, place a breakpoint in the first main()
statement, and press F6
when it pauses there.
My results (time in milliseconds) :
conn time total time
http (not stepping) 60 350
http (stepping over) 1100 1500
https (not stepping) 570 1300
https (stepping over) 21000 83000
Edit: after disabling Show method result after a step operation
option (the remedy aptly suggested by howlger's answer), the times become much more reasonable (about one-tenth for https).
http (stepping over 2) 150 450
https (stepping over 2) 2000 7000
My scenario: Java 8 (1.8.0_121-b13) , 64 bits, Win-7, Eclipse Photon (also experienced with Oxygen).
import java.io.*;
import java.net.*;
import java.nio.charset.StandardCharsets;
public class TestConn {
public static void downloadFromUrl(final URL url) throws IOException {
long t0 = System.currentTimeMillis();
URLConnection conn = url.openConnection();
System.out.println("conn msecs: " +
(System.currentTimeMillis() - t0) + " url=" + url);
System.out.println("=====================================");
try (BufferedReader in = new BufferedReader(
new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8))) {
String line;
int cont = 0;
while ((line = in.readLine()) != null) {
if (cont++ < 4)
System.out.println(line);
}
if(cont >=4)
System.out.printf("== total lines: %d (%d skipped)n",cont,cont-4);
System.out.println("==============done=======================");
}
}
public static void testConn(String urls) {
try {
long t0 = System.currentTimeMillis();
downloadFromUrl(new URL(urls));
System.out.println("Done , total time msecs: " +
(System.currentTimeMillis() - t0));
} catch (IOException e) {
e.printStackTrace();
}
}
public static void main(String args) throws Exception {
testConn("https://www.example.com/"); // breakpoint here, step-over with F6
System.out.println("bye");
}
}
java eclipse debugging networking
add a comment |
up vote
0
down vote
favorite
I'm trying to debug some problems with my Java code, which establishes a http/https connection. I'm wondering why the connection gets ridiculously slow (more than one minute for downloading a small web page) when debugging, even when stepping-over the method which does the network work. And if there is some remedy.
Below I post an example (you can change https:
to http:
, and try debugging this from Eclipse pressing F11
- for stepping, place a breakpoint in the first main()
statement, and press F6
when it pauses there.
My results (time in milliseconds) :
conn time total time
http (not stepping) 60 350
http (stepping over) 1100 1500
https (not stepping) 570 1300
https (stepping over) 21000 83000
Edit: after disabling Show method result after a step operation
option (the remedy aptly suggested by howlger's answer), the times become much more reasonable (about one-tenth for https).
http (stepping over 2) 150 450
https (stepping over 2) 2000 7000
My scenario: Java 8 (1.8.0_121-b13) , 64 bits, Win-7, Eclipse Photon (also experienced with Oxygen).
import java.io.*;
import java.net.*;
import java.nio.charset.StandardCharsets;
public class TestConn {
public static void downloadFromUrl(final URL url) throws IOException {
long t0 = System.currentTimeMillis();
URLConnection conn = url.openConnection();
System.out.println("conn msecs: " +
(System.currentTimeMillis() - t0) + " url=" + url);
System.out.println("=====================================");
try (BufferedReader in = new BufferedReader(
new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8))) {
String line;
int cont = 0;
while ((line = in.readLine()) != null) {
if (cont++ < 4)
System.out.println(line);
}
if(cont >=4)
System.out.printf("== total lines: %d (%d skipped)n",cont,cont-4);
System.out.println("==============done=======================");
}
}
public static void testConn(String urls) {
try {
long t0 = System.currentTimeMillis();
downloadFromUrl(new URL(urls));
System.out.println("Done , total time msecs: " +
(System.currentTimeMillis() - t0));
} catch (IOException e) {
e.printStackTrace();
}
}
public static void main(String args) throws Exception {
testConn("https://www.example.com/"); // breakpoint here, step-over with F6
System.out.println("bye");
}
}
java eclipse debugging networking
You aren't measuring what you think you are. Once a connection is established, the socket is held open; so it only has to connect once. Depending on the order of your tests, the first one is going to be slow. And then everything after that is faster. Which is to say your debugger isn't the root cause of the slow down.
– Elliott Frisch
Nov 10 at 23:32
@ElliottFrisch : My measures are done in differnt runs, hence they are different JVM instances, no chance of socket reuse. Furthermore, my results don't depend on the order. And in any case, 87 seconds to download a webpage, even from the coldest state, is absurd.
– leonbloy
Nov 10 at 23:36
1) When you connect a debug agent and set breakpoints, the JVM deoptimizes the code. This is liable to make it a lot slower. 2) I doubt that the Java team puts in a great deal of effort to make code run fast while being debugged. Why? Because most Java users don't care, and it is bad engineering to spend dev effort on things that people don't care about. 3) "Absurd" is your opinion. There is no scientific measure of "absurdity".
– Stephen C
Nov 11 at 4:12
4) If you really care .... then download OpenJDK and start investigating the JVM to figure out why this is slow. Once you have found the cause(s), develop patches to fix them and submit them to the OpenJDK team in the standard way.
– Stephen C
Nov 11 at 4:16
Apart from 4) there is no remedy.
– Stephen C
Nov 11 at 4:17
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm trying to debug some problems with my Java code, which establishes a http/https connection. I'm wondering why the connection gets ridiculously slow (more than one minute for downloading a small web page) when debugging, even when stepping-over the method which does the network work. And if there is some remedy.
Below I post an example (you can change https:
to http:
, and try debugging this from Eclipse pressing F11
- for stepping, place a breakpoint in the first main()
statement, and press F6
when it pauses there.
My results (time in milliseconds) :
conn time total time
http (not stepping) 60 350
http (stepping over) 1100 1500
https (not stepping) 570 1300
https (stepping over) 21000 83000
Edit: after disabling Show method result after a step operation
option (the remedy aptly suggested by howlger's answer), the times become much more reasonable (about one-tenth for https).
http (stepping over 2) 150 450
https (stepping over 2) 2000 7000
My scenario: Java 8 (1.8.0_121-b13) , 64 bits, Win-7, Eclipse Photon (also experienced with Oxygen).
import java.io.*;
import java.net.*;
import java.nio.charset.StandardCharsets;
public class TestConn {
public static void downloadFromUrl(final URL url) throws IOException {
long t0 = System.currentTimeMillis();
URLConnection conn = url.openConnection();
System.out.println("conn msecs: " +
(System.currentTimeMillis() - t0) + " url=" + url);
System.out.println("=====================================");
try (BufferedReader in = new BufferedReader(
new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8))) {
String line;
int cont = 0;
while ((line = in.readLine()) != null) {
if (cont++ < 4)
System.out.println(line);
}
if(cont >=4)
System.out.printf("== total lines: %d (%d skipped)n",cont,cont-4);
System.out.println("==============done=======================");
}
}
public static void testConn(String urls) {
try {
long t0 = System.currentTimeMillis();
downloadFromUrl(new URL(urls));
System.out.println("Done , total time msecs: " +
(System.currentTimeMillis() - t0));
} catch (IOException e) {
e.printStackTrace();
}
}
public static void main(String args) throws Exception {
testConn("https://www.example.com/"); // breakpoint here, step-over with F6
System.out.println("bye");
}
}
java eclipse debugging networking
I'm trying to debug some problems with my Java code, which establishes a http/https connection. I'm wondering why the connection gets ridiculously slow (more than one minute for downloading a small web page) when debugging, even when stepping-over the method which does the network work. And if there is some remedy.
Below I post an example (you can change https:
to http:
, and try debugging this from Eclipse pressing F11
- for stepping, place a breakpoint in the first main()
statement, and press F6
when it pauses there.
My results (time in milliseconds) :
conn time total time
http (not stepping) 60 350
http (stepping over) 1100 1500
https (not stepping) 570 1300
https (stepping over) 21000 83000
Edit: after disabling Show method result after a step operation
option (the remedy aptly suggested by howlger's answer), the times become much more reasonable (about one-tenth for https).
http (stepping over 2) 150 450
https (stepping over 2) 2000 7000
My scenario: Java 8 (1.8.0_121-b13) , 64 bits, Win-7, Eclipse Photon (also experienced with Oxygen).
import java.io.*;
import java.net.*;
import java.nio.charset.StandardCharsets;
public class TestConn {
public static void downloadFromUrl(final URL url) throws IOException {
long t0 = System.currentTimeMillis();
URLConnection conn = url.openConnection();
System.out.println("conn msecs: " +
(System.currentTimeMillis() - t0) + " url=" + url);
System.out.println("=====================================");
try (BufferedReader in = new BufferedReader(
new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8))) {
String line;
int cont = 0;
while ((line = in.readLine()) != null) {
if (cont++ < 4)
System.out.println(line);
}
if(cont >=4)
System.out.printf("== total lines: %d (%d skipped)n",cont,cont-4);
System.out.println("==============done=======================");
}
}
public static void testConn(String urls) {
try {
long t0 = System.currentTimeMillis();
downloadFromUrl(new URL(urls));
System.out.println("Done , total time msecs: " +
(System.currentTimeMillis() - t0));
} catch (IOException e) {
e.printStackTrace();
}
}
public static void main(String args) throws Exception {
testConn("https://www.example.com/"); // breakpoint here, step-over with F6
System.out.println("bye");
}
}
java eclipse debugging networking
java eclipse debugging networking
edited Nov 11 at 14:21
asked Nov 10 at 23:29
leonbloy
52.2k1797144
52.2k1797144
You aren't measuring what you think you are. Once a connection is established, the socket is held open; so it only has to connect once. Depending on the order of your tests, the first one is going to be slow. And then everything after that is faster. Which is to say your debugger isn't the root cause of the slow down.
– Elliott Frisch
Nov 10 at 23:32
@ElliottFrisch : My measures are done in differnt runs, hence they are different JVM instances, no chance of socket reuse. Furthermore, my results don't depend on the order. And in any case, 87 seconds to download a webpage, even from the coldest state, is absurd.
– leonbloy
Nov 10 at 23:36
1) When you connect a debug agent and set breakpoints, the JVM deoptimizes the code. This is liable to make it a lot slower. 2) I doubt that the Java team puts in a great deal of effort to make code run fast while being debugged. Why? Because most Java users don't care, and it is bad engineering to spend dev effort on things that people don't care about. 3) "Absurd" is your opinion. There is no scientific measure of "absurdity".
– Stephen C
Nov 11 at 4:12
4) If you really care .... then download OpenJDK and start investigating the JVM to figure out why this is slow. Once you have found the cause(s), develop patches to fix them and submit them to the OpenJDK team in the standard way.
– Stephen C
Nov 11 at 4:16
Apart from 4) there is no remedy.
– Stephen C
Nov 11 at 4:17
add a comment |
You aren't measuring what you think you are. Once a connection is established, the socket is held open; so it only has to connect once. Depending on the order of your tests, the first one is going to be slow. And then everything after that is faster. Which is to say your debugger isn't the root cause of the slow down.
– Elliott Frisch
Nov 10 at 23:32
@ElliottFrisch : My measures are done in differnt runs, hence they are different JVM instances, no chance of socket reuse. Furthermore, my results don't depend on the order. And in any case, 87 seconds to download a webpage, even from the coldest state, is absurd.
– leonbloy
Nov 10 at 23:36
1) When you connect a debug agent and set breakpoints, the JVM deoptimizes the code. This is liable to make it a lot slower. 2) I doubt that the Java team puts in a great deal of effort to make code run fast while being debugged. Why? Because most Java users don't care, and it is bad engineering to spend dev effort on things that people don't care about. 3) "Absurd" is your opinion. There is no scientific measure of "absurdity".
– Stephen C
Nov 11 at 4:12
4) If you really care .... then download OpenJDK and start investigating the JVM to figure out why this is slow. Once you have found the cause(s), develop patches to fix them and submit them to the OpenJDK team in the standard way.
– Stephen C
Nov 11 at 4:16
Apart from 4) there is no remedy.
– Stephen C
Nov 11 at 4:17
You aren't measuring what you think you are. Once a connection is established, the socket is held open; so it only has to connect once. Depending on the order of your tests, the first one is going to be slow. And then everything after that is faster. Which is to say your debugger isn't the root cause of the slow down.
– Elliott Frisch
Nov 10 at 23:32
You aren't measuring what you think you are. Once a connection is established, the socket is held open; so it only has to connect once. Depending on the order of your tests, the first one is going to be slow. And then everything after that is faster. Which is to say your debugger isn't the root cause of the slow down.
– Elliott Frisch
Nov 10 at 23:32
@ElliottFrisch : My measures are done in differnt runs, hence they are different JVM instances, no chance of socket reuse. Furthermore, my results don't depend on the order. And in any case, 87 seconds to download a webpage, even from the coldest state, is absurd.
– leonbloy
Nov 10 at 23:36
@ElliottFrisch : My measures are done in differnt runs, hence they are different JVM instances, no chance of socket reuse. Furthermore, my results don't depend on the order. And in any case, 87 seconds to download a webpage, even from the coldest state, is absurd.
– leonbloy
Nov 10 at 23:36
1) When you connect a debug agent and set breakpoints, the JVM deoptimizes the code. This is liable to make it a lot slower. 2) I doubt that the Java team puts in a great deal of effort to make code run fast while being debugged. Why? Because most Java users don't care, and it is bad engineering to spend dev effort on things that people don't care about. 3) "Absurd" is your opinion. There is no scientific measure of "absurdity".
– Stephen C
Nov 11 at 4:12
1) When you connect a debug agent and set breakpoints, the JVM deoptimizes the code. This is liable to make it a lot slower. 2) I doubt that the Java team puts in a great deal of effort to make code run fast while being debugged. Why? Because most Java users don't care, and it is bad engineering to spend dev effort on things that people don't care about. 3) "Absurd" is your opinion. There is no scientific measure of "absurdity".
– Stephen C
Nov 11 at 4:12
4) If you really care .... then download OpenJDK and start investigating the JVM to figure out why this is slow. Once you have found the cause(s), develop patches to fix them and submit them to the OpenJDK team in the standard way.
– Stephen C
Nov 11 at 4:16
4) If you really care .... then download OpenJDK and start investigating the JVM to figure out why this is slow. Once you have found the cause(s), develop patches to fix them and submit them to the OpenJDK team in the standard way.
– Stephen C
Nov 11 at 4:16
Apart from 4) there is no remedy.
– Stephen C
Nov 11 at 4:17
Apart from 4) there is no remedy.
– Stephen C
Nov 11 at 4:17
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
That's why in Window > Preferences: Java > Debug there is the preference Show method result after a step operation (if supported by the VM; maybe slow).
Since Eclipse 2018-09 (4.9) a timeout (7 seconds by defaults) can be set for that:
- Eclipse 4.9 - New and Noteworthy - Timeout for result of step operation
- Short video of this new feature
Well, this was useful. Thanks.
– leonbloy
Nov 11 at 14:01
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
That's why in Window > Preferences: Java > Debug there is the preference Show method result after a step operation (if supported by the VM; maybe slow).
Since Eclipse 2018-09 (4.9) a timeout (7 seconds by defaults) can be set for that:
- Eclipse 4.9 - New and Noteworthy - Timeout for result of step operation
- Short video of this new feature
Well, this was useful. Thanks.
– leonbloy
Nov 11 at 14:01
add a comment |
up vote
1
down vote
accepted
That's why in Window > Preferences: Java > Debug there is the preference Show method result after a step operation (if supported by the VM; maybe slow).
Since Eclipse 2018-09 (4.9) a timeout (7 seconds by defaults) can be set for that:
- Eclipse 4.9 - New and Noteworthy - Timeout for result of step operation
- Short video of this new feature
Well, this was useful. Thanks.
– leonbloy
Nov 11 at 14:01
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
That's why in Window > Preferences: Java > Debug there is the preference Show method result after a step operation (if supported by the VM; maybe slow).
Since Eclipse 2018-09 (4.9) a timeout (7 seconds by defaults) can be set for that:
- Eclipse 4.9 - New and Noteworthy - Timeout for result of step operation
- Short video of this new feature
That's why in Window > Preferences: Java > Debug there is the preference Show method result after a step operation (if supported by the VM; maybe slow).
Since Eclipse 2018-09 (4.9) a timeout (7 seconds by defaults) can be set for that:
- Eclipse 4.9 - New and Noteworthy - Timeout for result of step operation
- Short video of this new feature
answered Nov 11 at 12:25
howlger
9,57051636
9,57051636
Well, this was useful. Thanks.
– leonbloy
Nov 11 at 14:01
add a comment |
Well, this was useful. Thanks.
– leonbloy
Nov 11 at 14:01
Well, this was useful. Thanks.
– leonbloy
Nov 11 at 14:01
Well, this was useful. Thanks.
– leonbloy
Nov 11 at 14:01
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53244437%2fwhy-https-connections-are-so-slow-when-debugging-stepping-over-in-java%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You aren't measuring what you think you are. Once a connection is established, the socket is held open; so it only has to connect once. Depending on the order of your tests, the first one is going to be slow. And then everything after that is faster. Which is to say your debugger isn't the root cause of the slow down.
– Elliott Frisch
Nov 10 at 23:32
@ElliottFrisch : My measures are done in differnt runs, hence they are different JVM instances, no chance of socket reuse. Furthermore, my results don't depend on the order. And in any case, 87 seconds to download a webpage, even from the coldest state, is absurd.
– leonbloy
Nov 10 at 23:36
1) When you connect a debug agent and set breakpoints, the JVM deoptimizes the code. This is liable to make it a lot slower. 2) I doubt that the Java team puts in a great deal of effort to make code run fast while being debugged. Why? Because most Java users don't care, and it is bad engineering to spend dev effort on things that people don't care about. 3) "Absurd" is your opinion. There is no scientific measure of "absurdity".
– Stephen C
Nov 11 at 4:12
4) If you really care .... then download OpenJDK and start investigating the JVM to figure out why this is slow. Once you have found the cause(s), develop patches to fix them and submit them to the OpenJDK team in the standard way.
– Stephen C
Nov 11 at 4:16
Apart from 4) there is no remedy.
– Stephen C
Nov 11 at 4:17