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");
}
}









share|improve this question
























  • 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















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");
}
}









share|improve this question
























  • 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













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");
}
}









share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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


















  • 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












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






share|improve this answer





















  • Well, this was useful. Thanks.
    – leonbloy
    Nov 11 at 14:01











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















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

























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






share|improve this answer





















  • Well, this was useful. Thanks.
    – leonbloy
    Nov 11 at 14:01















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






share|improve this answer





















  • Well, this was useful. Thanks.
    – leonbloy
    Nov 11 at 14:01













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






share|improve this answer












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







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 11 at 12:25









howlger

9,57051636




9,57051636












  • 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




Well, this was useful. Thanks.
– leonbloy
Nov 11 at 14:01


















 

draft saved


draft discarded



















































 


draft saved


draft discarded














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





















































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







Popular posts from this blog

Full-time equivalent

Bicuculline

さくらももこ