Профилировщик NetBeans, показывающий значительно разные времена выполнения

Question

Я сравниваю два алгоритма решения проблемы запроса Skyline в файле с двумерными точками.

Я объявляю их:

SkylineAlgorithm bnl = new BNL(); SkylineAlgorithm sfs = new SFS();

Затем вручную измерить их эффективность:

long startTime = System.nanoTime(); 
List<Point> skylinesBnl = bnl.getSkylinePoints(file); 
long endTime = System.nanoTime(); 
long durationBnl = (endTime - startTime)/1000000; 

startTime = System.nanoTime(); 
List<Point> skylinesSfs = sfs.getSkylinePoints(file); 
endTime = System.nanoTime(); 
long durationSfs = (endTime - startTime)/1000000; 

System.out.println("BNL: " + durationBnl + " ms"); 
System.out.println("SFS: " + durationSfs + " ms"); 

Например, это будет печатать:

BNL: 4648 ms 
SFS: 4946 ms 

Тогда я думал использовать что-то еще сложный, как профилировщик NetBeans. Я установил метод профилирования корня getSkylinePoints(file) (оба алгоритма совместно используют этот метод, хотя шаблон шаблона метода шаблона), а затем в конце строки List<Point> skylinesBnl = bnl.getSkylinePoints(file); Я установил профилировщик для сохранения результатов и вывода их. То же самое происходит для sfs.

Мои результаты таким образом, эти (открытые изображения в новой вкладке):

BNL:

SFS:

То есть значительно отличается от того, что я получаю в ручном режиме. Любые идеи, что происходит?

Answer 1

Ответ прост: getPointRDDFromTextFile, очевидно, использует дисковый ввод-вывод и производит более сложный результат. Если вы избавитесь от ввода-вывода, вы значительно сократите время выполнения. Доступ к дискам любого (!) Типа всегда очень медленный - по дизайну.

То же самое верно и для сокетов любого вида (для розеток, кроме как для труб, находящихся в памяти), следовательно, передачи данных WAN/LAN, а также рекурсивные алгоритмы любого рода (из-за стека-умножения)

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