Вопрос о неэффективности условных точек останова Eclipse Java Debugger - PullRequest
2 голосов
/ 14 мая 2010

Я просто установил условную точку останова в отладчике Eclipse с умеренно неэффективным условием по стандартам точек останова - проверяя, содержит ли список значений HashMap (8 элементов) Double.NaN. Это привело к чрезвычайно заметному снижению производительности - примерно через пять минут я сдался.

Затем я скопировал и вставил условие в оператор if в той же строке, вставил noop в if и установил там нормальную точку останова. Эта точка останова была достигнута в ожидаемые 20-30 секунд.

Есть ли что-то особенное, что делают условные точки останова, которые приносят пользу производительности, или реализация Eclipse просто глупа? Кажется, что они могли бы довольно легко просто сделать то же самое (вставить в if и скомпилировать) за кулисами.

Ответы [ 3 ]

2 голосов
/ 22 мая 2010

Интересно!

Я играл с некоторым исходным кодом, чтобы увидеть, что происходит с условной точкой останова и без нее. Прилагается ниже.

Выполнение в отладчике с условной точкой останова:
Продолжительность: 1210623 микросекунд

Выполнение в отладчике без условной точки останова:
Продолжительность: 24 мкс

ИМХО, ВМ не остановлена, поскольку второй поток продолжает работать рядом. Eclipse должен внедрить код точки останова в текущий класс. Возможно, это происходит при каждом вызове, и, возможно, приходится перекомпилировать класс при каждом вызове. Проверка источников Eclipse покажет, что именно происходит.

Мой опыт работы с условными контрольными точками в C # и в Visual Studio еще хуже: у меня такое чувство, что все на пару порядков хуже.

public class BreakPointPlay {

static int breakpointHits;

static volatile int modifiedBySecondThread;

static volatile boolean stopped;

public static void main(String[] args) throws InterruptedException {

    Thread secondThread = startSecondThread();

    final long LOOPS = 1000;
    long counter = 0;
    long start = System.nanoTime();
    for (long i = 0; i < LOOPS; i++) {

        // place breakpoint here and set the condition to the
        // #breakPointCondition() method.
        counter += i;

    }
    long stop = System.nanoTime();
    long nanos = stop - start;
    long micros = nanos / 1000;

    System.out.println("\nDuration: " + micros + " microseconds\n");

    printInfo();
    stopped = true;

    secondThread.join();
}

private static Thread startSecondThread() {
    Thread thread = new Thread(new Runnable() {
        @Override
        public void run() {
            while(! stopped){
                modifiedBySecondThread++;
            }
        }
    });
    thread.start();
    return thread;
}

private static void printInfo() {
    printModifiedBySecondThread();
    printThread();
    printClassLoader();
    printStackTrace();
    printModifiedBySecondThread();
}

private static void printStackTrace() {
    Exception exception = new Exception();
    exception.fillInStackTrace();
    exception.printStackTrace(System.out);
}

private static void printModifiedBySecondThread() {
    print("modifiedBySecondThread " + modifiedBySecondThread);
}

public static boolean breakPointCondition(){
    breakpointHits++;
    if(breakpointHits == 100){
        printInfo();
    }
    return false;
}

private static void printClassLoader() {
    print("ClassLoader " + new BreakPointPlay().getClass().getClassLoader());
}

private static void printThread() {
    print("Thread " + Thread.currentThread());
}

private static void print(String msg){
    System.out.println(msg);
}


}
0 голосов
/ 14 мая 2010

Eclipse должен остановить всю JVM, чтобы проверить состояние точки останова. Вот почему это стоит вам.

0 голосов
/ 14 мая 2010

Сколько раз была пройдена точка останова? Может случиться так, что отладчику приходилось проверять состояние точки останова много раз, прежде чем он сработал. Я не знаю, как это реализовано, но я не удивлюсь, если выполнение условия отладчиком будет намного менее эффективным, чем было бы скомпилированной Java. Возможно, это просто то, что он получает меньше внимания от JIT. Возможно, он даже не полностью скомпилирован в Java и интерпретируется.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...