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

    }

}

edited Nov 11 at 14:21

asked Nov 10 at 23:29

leonbloy

52.3k1798144

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

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

    }

}

edited Nov 11 at 14:21

asked Nov 10 at 23:29

leonbloy

52.3k1798144

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

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

    }

}

edited Nov 11 at 14:21

asked Nov 10 at 23:29

leonbloy

52.3k1798144

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

edited Nov 11 at 14:21

asked Nov 10 at 23:29

leonbloy

52.3k1798144

edited Nov 11 at 14:21

asked Nov 10 at 23:29

leonbloy

52.3k1798144

edited Nov 11 at 14:21

asked Nov 10 at 23:29

leonbloy

52.3k1798144

asked Nov 10 at 23:29

leonbloy

52.3k1798144

asked Nov 10 at 23:29

leonbloy

52.3k1798144

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

@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 |

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

answered Nov 11 at 12:25

howlger

9,64551636

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

add a comment |

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

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

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

Name

Required, but never shown

1 Answer
1

active

oldest

votes

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

answered Nov 11 at 12:25

howlger

9,64551636

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

answered Nov 11 at 12:25

howlger

9,64551636

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

answered Nov 11 at 12:25

howlger

9,64551636

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,64551636

answered Nov 11 at 12:25

howlger

9,64551636

answered Nov 11 at 12:25

howlger

9,64551636

answered Nov 11 at 12:25

howlger

9,64551636

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

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

Some of your past answers have not been well-received, and you're in danger of being blocked from answering.

Please pay close attention to the following guidance:

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Agfdhyk