Oracle анонсирует бесплатную и Premium версии Java VM

> Kron телал такие замеры. Именно процесса выделения памяти/освобождения. http://balancer.ru/tech/forum/2008/08/t63003--proizvoditelnost-yazykov-obektn...

И где там код на Java, результаты которого приведены в таблице? И с какими ключами он был запущен?

>А я говорил, что он быстрый?

вы опровергаете моё утверждение, что он медленный:

grim> Overhead в Java при вызове Native кода обычно больше чем выиграх от его использования.

rtvd>Когда ты последний раз его замерял? То-то же.

при наличии минимальных способностей к логическому мыщлению, любой человек сделает вывод, что overhead уже отстутствует, так вы попровергаете поё высказывание => он быстрый.

или это не вы писали?

ps
Остально, я так понял - секретные знания.

И где там код на Java, результаты которого приведены в таблице? И с какими ключами он был запущен?

А вы кликните на линк. Там всё есть. Производительность языков. Объектный Фибоначчи :)

> вы опровергаете моё утверждение, что он медленный:

grim> Overhead в Java при вызове Native кода обычно больше чем выиграх от его использования.
rtvd>Когда ты последний раз его замерял? То-то же.

Нет, я опровергал утверждение, что он _обычно больше_ чем выигрыш от его использования. Везде свое «обычно».

при наличии минимальных способностей к логическому мыщлению, любой человек сделает вывод, что overhead уже отстутствует, так вы попровергаете поё высказывание => он быстрый.

Видимо логика, которой Вы руководствуетесь очень необычна. Вероятность встретить динозавра на улице - 50%/50%?

> Кто такая Монако? если аналитика то там всего хватает.

Мы говорим об одном и том-же Royal Bank Capital Markets?

200 Wellington St W Money Market Trading System (бонды, ценные бумаги и пр)

> В принципе я просто хотел сказать что всему своё место. Инормально написанная программа на С++ не падает годами. Пример - Беларусьтелеком где стоят системы АПУС, с аптаймом по несколько лет и перегружаемые только иззи проблем с железом(привет Белавоксу). И на Java можно ниписать кривые программы, что я регулярно наблюдаю.

С этим-то и я согласен. Вот только почему-то Вы переносите проблемы криворуких писак на язык. Это по сути единственное, с чем я не согласен.

По-моему мнению, жаба неплохой язык. Да, местами не идеален. Но для большинства случаев он хорош. И основные проблемы с производительностью обычно возникают не из-за языка, а из-за криворукости отдельных особей.

и, это аналитика/фронтэнд или взаимодействие с биржей?
Я, естетсвенно, всего там знать не могу но как я писал там и Java и .Net и много чего ещё. Но взаимодействие с биржей (то что я видел) было на С++

> Я писал программы на Java с откликом в микросекундах. Самый большой кусок времени выполнения - отправка данных на сетевой интерфес.

Безусловно, он был в микросекундах. Только это, вероятно, были сотни микросекунд, не так ли?

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

При этом программа еще и вела полноценные логи

Ага, добавим сюда, минимум, переключение контекста, максимум - «полноценную» запись с flush-ем - еще до сотни-двух микросекунд.

и не вылетала по сегфолтам, как принято у плюсовиков.

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

Ну а как именно я это делаю - знать Вам не обязательно. :-)

А и правда, в яве же нет нативного способа узнать текущее время с точностью до микросекунд? Как же замерялось время отклика в микросекундах?

>Вот только почему-то Вы переносите проблемы криворуких писак на язык.
Это вы переносите. на С++
При этом криворукость не зависит от языка. Но если как С++ крограммер такой калека не выживет, то как Java программер - запросто.

как .Net впрочем тоже.

Но это не недостаток технологии естественно.

> и, это аналитика/фронтэнд или взаимодействие с биржей?

Это всё, и фронт-энд и buy/sell интеракция с различными трейдинговыми системами

Начиная с 1.5

System.nanoTime()

Returns the current value of the most precise available system timer, in nanoseconds.

> В жабе выделение небольшого блока памяти занимает порядка 1-3 наносекунды.

Ух-ты! А как это замеряли? Лучший кандидат для замера, функция nanoTime, сама почти тысячу наносекунд вызывается.

> System.nanoTime() Returns the current value of the most precise available system timer, in nanoseconds.

Это - не время, а какой-то никому не известный счетчик. С его помощью можно замерять время выполнения куска кода внутри одного потока. Но измерить время передачи от одного приложения до другого нельзя. Особенно, если приложения - на разных языках.

Всё меняется.
Ок буду знать :)

ps
Эх, весёлые были времена.
Иногда прямо ностальгия накатывает :)

Я сечас из дома работаю. Начал даже скучать по оффисам за пол года

Вообщем, Оракловцы разъяснили что волноваться не надо
http://robilad.livejournal.com/69461.html
http://blogs.oracle.com/henrik/2010/11/oracles_jvm_strategy.html

> Пока что рекорд такой:

Haskell: ~50 строк C++: ~1000 строк

Поделитесь задачей, интересно же попробовать и свои силы...

С++ серверы o которых я говорил работает в Meril Lynch, RBC Capital Markets и нескольких мелких трэйдинговых конторах.

Ну вот сделали люди в Англии на жабе трейдинговую платформу. С максимальной задержкой обслуживания транзакции 1мс.

Пока что рекорд такой:

просто любопытно что такая программа делает полезного? берет какие-то данные в файлах, делает обсчет и складывает в новые файлы?

> Есть класс. У него есть поле с типом, скажем, Object (ссылка на что-нибудь). Далее есть цикл, что делает с десяток итераций. В каждой итерации замеряется время начала, делается цикл в 1e9 операций, замеряется время конца, печатается разница между началом и концом. Операция во внутреннем цикле: this.obj = new Object();

Нельзя так замерять. Любой мало-мальски умный транслятор заметит, что результат операции не зависит от итерации цикла и вынесет эту операцию за цикл. В результате измеряться будет ОДНО выделение и пустой цикл.

Тут, на ЛОРе, несколько раз выкладывали замеры скорости. Явашное выделение памяти было немного (раза в два) медленнее сиплюсплюсного.

GHC бывает работает пошустрее.

Еще бы... Он же транслирует свой код в Си.

А я наоборот, все хочу забить на работу из офиса и работать из дома :)

>> Я писал программы на Java с откликом в микросекундах. Самый большой кусок времени выполнения - отправка данных на сетевой интерфес.

Безусловно, он был в микросекундах. Только это, вероятно, были сотни микросекунд, не так ли?

Неа. Заметно меньше. Пакет небольшой, машина - шустрая и оттюненая.

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

Время отправки != время передачи.

При этом программа еще и вела полноценные логи

Ага, добавим сюда, минимум, переключение контекста, максимум - «полноценную» запись с flush-ем - еще до сотни-двух микросекунд.

Ну-ну. :)

и не вылетала по сегфолтам, как принято у плюсовиков.

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

Само собой кое-что - асинхронное. Но только то, что нужно.

Ну а как именно я это делаю - знать Вам не обязательно. :-)

А и правда, в яве же нет нативного способа узнать текущее время с точностью до микросекунд? Как же замерялось время отклика в микросекундах?

В пределах одного потока - легко. System.nanoTime()

Явашное выделение памяти было немного (раза в два) медленнее сиплюсплюсного

А в моно и сисярпе выделение памяти даже быстрее сиплюсплюсного, доказано здесь http://habrahabr.ru/blogs/net/107585

>> Есть класс. У него есть поле с типом, скажем, Object (ссылка на что-нибудь). Далее есть цикл, что делает с десяток итераций. В каждой итерации замеряется время начала, делается цикл в 1e9 операций, замеряется время конца, печатается разница между началом и концом. Операция во внутреннем цикле: this.obj = new Object();

Нельзя так замерять. Любой мало-мальски умный транслятор заметит, что результат операции не зависит от итерации цикла и вынесет эту операцию за цикл. В результате измеряться будет ОДНО выделение и пустой цикл.

Мало-мальски внимательный человек заметит, что это он будет делать только тогда, когда поле не объявлено как volatile.

Тут, на ЛОРе, несколько раз выкладывали замеры скорости. Явашное выделение памяти было немного (раза в два) медленнее сиплюсплюсного.

GHC бывает работает пошустрее.

Еще бы... Он же транслирует свой код в Си.

О да, конечно. :) А еще компилит сам и через LLVM. Только собака зарыта в другом месте. Но анонимы исходники GHC обычно не читают, им проще гадать на кофейной куще.

>А я наоборот, все хочу забить на работу из офиса и работать из дома :)
Ага, я тоже так обрадовался вначале :)

Но через пол года начал скучать по общению.

Мы собираемся время от времени - контракторы из CM пива попить в Crocodile Rock

Сейчас конечно уже кто-где, но пообщаться все рано приятно. Фултаймеров не прогоняем если они не вредные :)
я grim.vx на джимэйле .

Тут, на ЛОРе, несколько раз выкладывали замеры скорости. Явашное выделение памяти было немного (раза в два) медленнее сиплюсплюсного.

Не верю. В реальной фрагментированной куче malloc очень долго выделяет память. В джаве это несколько машинных команд, по сути сдвинуть один указатель на нужный размер.

> Мало-мальски внимательный человек заметит, что это он будет делать только тогда, когда поле не объявлено как volatile.

Вообще-то volatile указывает на то, что значение переменной не надо кешировать внутри потока. Но не указывает, что его нужно перезаписывать несколько раз вместо одного. На месте транслятора команды:
a = 1;
a = 2;
a = 3;
a = 4;
a = 5;
абсолютно логично заменить на:
a = 5;
вне зависимости от того, volatile «a» или нет.

Вместо 1 миллиарда выделений будет сделано только ОДНО. А потом, разделив время выполнения пустого цикла и ОДНОГО выделения памяти на миллиард, внезапно будут получены 3 наносекунды.

делается цикл в 1e9 операций

1e9

Точно, одно выделение. Иначе по окончании этого цикла были бы выделены десятки гигабайт памяти. Вот и раскрылась тайна трех наносекунд.

Еще бы... Он же транслирует свой код в Си.

О да, конечно. :) А еще компилит сам и через LLVM.

Конечно, в оригинальном сообщении это была ирония. :) Хотя ghc действительно умеет генерировать сишные исходники.

> Не верю. В реальной фрагментированной куче malloc очень долго выделяет память. В джаве это несколько машинных команд, по сути сдвинуть один указатель на нужный размер.

В теме уже давали эту ссылку. Гугль по «linux.org.ru скорость выделения памяти java C++» выдал еще одну ссылку.

Судя по ним malloc действительно работает медленнее new в java, но в сях++ malloc/new - не единственный способ выделения. Для явы, походу, там тоже несколько результатов есть.

> Вообще-то volatile указывает на то, что значение переменной не надо кешировать внутри потока. Но не указывает, что его нужно перезаписывать несколько раз вместо одного. На месте транслятора команды:

a = 1;

a = 2;

a = 3;

a = 4;

a = 5;

абсолютно логично заменить на:

a = 5;

вне зависимости от того, volatile «a» или нет.

Вы случаем не пишете компиляторы и всякие-там оптимизаторы кода? Если пишете, будьте добры сказать, какие имеено. Я буду обходить их стороной.

Ваша «оптимизация» несовместима с семантикой «volatile» и делаеть ее нельзя. Хорошо что JVM об этом знает.

Точно, одно выделение. Иначе по окончании этого цикла были бы выделены десятки гигабайт памяти. Вот и раскрылась тайна трех наносекунд.

Вы себя хорошо чувствуете?

Код выглядит приблизительно так:

int N = 1000000000;

long start = System.nanoTime();

for(int i = 0; i < N; i++) {

this.o = new Object();

}

long end = System.nanoTime();

System.out.println((end-start)/N);

Если бы цикл «соптимизировали», то результат был бы 0. А он не 0. Зато становится нулем, если убрать строчку с «new Object()».

> А в моно и сисярпе выделение памяти даже быстрее сиплюсплюсного, доказано здесь http://habrahabr.ru/blogs/net/107585

Доля правды там есть, но считать это именно доказательством это по-моему слишком.

> Ваша «оптимизация» несовместима с семантикой «volatile» и делаеть ее нельзя. Хорошо что JVM об этом знает.

В таком случае, если не трудно, можно ссылочку на семантику volatile в JVM? Я пополню свои знания.

> Код выглядит приблизительно так: [...]

Код - это хорошо. Вы не будете возражать, если я его проверю?

$ cat NewSpeed.java
class NewSpeed
{
  private Object o;

  NewSpeed(int n)
  {
    for(int i = 0; i < n; i++) {
      this.o = new Object();
    }
  }

  public static void main(String[] args)
  {
    int N = 1000000000;
    long start = System.nanoTime();
    NewSpeed test = new NewSpeed(N);
    long end = System.nanoTime();
    System.out.println((end-start)/N);
  }
}

$ javac NewSpeed.java && time java NewSpeed
8

real    0m8.616s
user    0m8.307s
sys     0m0.194s

Что ж, я не возражаю против этих результатов. Я всего лишь не верю, что там действительно что-то выделяется. Транслятор мог, например, сделать одно выделение, а потом в миллиард раз его присвоить. А что если эти 8 наносекунд - это ТОЛЬКО ПРИСВАИВАНИЕ?

Еще, если бы на каждой итерации выделялся хотя бы один байт, то всей программе выделилось бы не меньше гигабайта. Однако она не требует столько памяти, странно, правда?

Давайте попробуем выделить более настоящий объект, такой, выделение которого транслятор не сможет соптимизировать? Как на счет такого кода:

$ cat NewSpeed2.java
class NewSpeed2
{
  public int n;
  NewSpeed2(int n)
  {
    this.n = n;
  }

  public static void main(String[] args)
  {
    int N = 10000000;
    NewSpeed2[] o = new NewSpeed2[N];

    long start = System.nanoTime();
    for (int i = 0; i < N; i++)
      o[i] = new NewSpeed2(i);
    long end = System.nanoTime();

    System.out.println((end-start)/N);

    long debugsum = 0;
    start = System.nanoTime();
    for (int i = 0; i < N; i++)
      debugsum += o[i].n;
    end = System.nanoTime();

    System.out.println((end-start)/N);
    System.out.println(debugsum);
  }
}

$ javac NewSpeed2.java && time java NewSpeed2
465
11
49999995000000

real    0m5.055s
user    0m4.776s
sys     0m0.882s

Оп-па. Внезапно 8 наносекунд превратились в пол сотни. Hе могли бы вы объяснить, куда же пропали наносекунды на выделение?

А еще, во втором цикле, примерно 11 наносекунд выполняется ТОЛЬКО ПРИСВАИВАНИЕ СО СЛОЖЕНИЕМ. Почти как 8 наносекунд в первом тесте. Какое забавное совпадение, правда?

> Внезапно 8 наносекунд превратились в пол сотни.

Извиняюсь, в пол ТЫСЯЧИ, описка вышла

Во втором случае GC сходит с ума из за огромного количества маленьких объектов, которые никак не освобождаются. Его надо потюнить или сделать тупо:

java -Xms1g NewSpeed2

31
10
49999995000000

> Домашний сервер это ARM 1Ghz/512mb RAM

Сравнивать будем запустится ли оно вообще azureus+ваш аналог астерикса.

у меня нет такого сервера, потому проверить работу не могу. аналог астериска - не мой и стоит денег. Покупать не буду ибо не нужно ;)

Я видел Астерикс в работе небольших конторах(до 1000 человек на телефонах) и связью он обеспечивал без проблем, хотя логи я конечно-же не смотрел. Может он и падал.

тестили для колл-центра маленьких американских банков =))) нуно было чтобы работало как часы.

В принципе я просто хотел сказать что всему своё место. Инормально написанная программа на С++ не падает годами.

Согласен. Я против огульного порицания программы из-за языка на котором разработана. И на Java можно написать биллинг и на C/C++. А можно сделать настолько убого, что пипец... и это вне зависимости от языка.

По мне плюс java это ортогональность языка (одна вещь делается одним способом) и большая базовая библиотека. Примерно как С++ + boost + STL ;)

> Kron телал такие замеры. Именно процесса выделения памяти/освобождения.

http://balancer.ru/tech/forum/2008/08/t63003--proizvoditelnost-yazykov-obektn...

а понта в таком тесте? вы пишете программу чтобы выделять/освобождать память ИЛИ выполнять алгоритм?

> В таком случае, если не трудно, можно ссылочку на семантику volatile в JVM? Я пополню свои знания.

Спецификация - тут, разбирайтесь. http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html

«A store action by T on V is permitted only if the previous action by T on V was assign, and an assign action by T on V is permitted only if the next action by T on V is store.»

Что ж, я не возражаю против этих результатов. Я всего лишь не верю, что там действительно что-то выделяется. Транслятор мог, например, сделать одно выделение, а потом в миллиард раз его присвоить. А что если эти 8 наносекунд - это ТОЛЬКО ПРИСВАИВАНИЕ?

Присваивание чего? Все объекты, что создаются - разные. Это тебе не константа. Хочешь проверить - вынеси создание объекта из цикла.

Оп-па. Внезапно 8 наносекунд превратились в пол сотни. Hе могли бы вы объяснить, куда же пропали наносекунды на выделение?

Ну абзац. Выделил массив и создал кучу долгоживущих объектов. Причем объекты, вероятно, уже ушли из зоны Eden. Это ж кем надо быть, чтобы ТАК не понимать принцип работы GC и кешей.

А еще, во втором цикле, примерно 11 наносекунд выполняется ТОЛЬКО ПРИСВАИВАНИЕ СО СЛОЖЕНИЕМ. Почти как 8 наносекунд в первом тесте. Какое забавное совпадение, правда?

Какое совпадение, что человек, что гонит на жабку, вообще не понимает как работает она и компьютер... :-)

> Оп-па. Внезапно 8 наносекунд превратились в пол сотни. Hе могли бы вы объяснить, куда же пропали наносекунды на выделение?

Попробуй переписать свой второй пример (тот, что с массивом) на C или C++ и глянь на цифры. Если цифры маленькие - покажи код, я покажу тебе где у тебя ошибка. %)

> Выделил массив и создал кучу долгоживущих объектов.

Зато можно быть уверенным, что память под них реально выделилась.

Это ж кем надо быть, чтобы ТАК не понимать принцип работы GC и кешей.

Тобой?

> Во втором случае GC сходит с ума из за огромного количества маленьких объектов, которые никак не освобождаются.

А почему он с ума сходит? Ну, много маленьких объектов. Ну, не осовбождаются. И что? Это же штатная ситуация.

Появились небольшие подробности:

http://blogs.oracle.com/henrik/2010/11/oracles_jvm_strategy.html

http://robilad.livejournal.com/69461.html

>> Выделил массив и создал кучу долгоживущих объектов.

Зато можно быть уверенным, что память под них реально выделилась.

Если Вы столь неуверенны, то чем я могу помочь? :)

Это ж кем надо быть, чтобы ТАК не понимать принцип работы GC и кешей.

Тобой?

Ню-ню.

> А почему он с ума сходит? Ну, много маленьких объектов. Ну, не осовбождаются. И что? Это же штатная ситуация.

Во-первых, с ума он не сходит.

Во-вторых, память начинает выделяться не в Eden зоне (что играет роль своеобразного стека), а в общей куче. Оттого и разница в производительности.

В-третьих, программа на C или плюсах в этом случае или обожрется памяти и сдохнет, либо долна будет использовать свой аллокатор. Аналогичного эффекта в Java можно добиться с меньшим геммороем, передав java процессу ключик, увеличивающий зону Eden.

Штатная ситуация.. Штатная ситуация также то, что кое-кто горазд сравнивать ужа с ежем и удивляться «большой разнице».

> В-третьих, программа на C или плюсах в этом случае или обожрется памяти и сдохнет, либо долна будет использовать свой аллокатор. Аналогичного эффекта в Java можно добиться с меньшим геммороем, передав java процессу ключик, увеличивающий зону Eden.

Под «сдохнет», я конечно же, имею в виду ситуацию со stack overflow, если какой-нибудь умник будет «обгонять» жабку при помощи alloca.

А почему он с ума сходит? Ну, много маленьких объектов. Ну, не осовбождаются. И что? Это же штатная ситуация.

Там примерно так происходит. Есть некий довольно маленький пул изначально. В первом случае он заполняется, запускается GC, весь этот пул очищает сразу, и дальше работает. Пул маленький, очищается быстро.

Во втором случае этот пул заполняется полностью. Он проводит GC, ничего не освобождается. Он его расширяет (возможно выделяя новый кусок памяти и копируя туда всё что есть), и дальше работает. Этот новый пул опять заполняется. И т.д. В итоге получается, что на сборку мусора тратится много времени. Если сразу задать большой размер пула, то никаких перемещений не производится.

В обычном режиме работы много мелких объектов появляется и большинство из них тут же становятся доступными для сборки мусора, и довольно быстро собираются. Некоторые объекты получаются долгоживущими, и перемещаются в область для долгоживущих объектов. Стандартные сборщики мусора заточены именно под этот режим работы а не для пятисекундных бенчмарков.

> Там примерно так происходит. Есть некий довольно маленький пул изначально. В первом случае он заполняется, запускается GC, весь этот пул очищает сразу, и дальше работает. Пул маленький, очищается быстро.

Я бы еще добавил, что в нормальных GC есть два пула. Когда заполняется один, начинает использоваться другой, а в фоновом режиме (в другом потоке) живые объекты из первого пула переносятся во второй. Таких объектов, как правило, мало. А далее, «высвобождение памяти» в первом пуле это просто установка на нем флага, что он свободен.

Короче, сделать на C++ свой аллокатор, что будет работать не глупее чем аллокатор Java это работа явно не на пол часа. Но если кто хочет, пусть пробует. Просто умные люди не решают проблемы, они себе их не создают.

>а понта в таком тесте? вы пишете программу чтобы выделять/освобождать память ИЛИ выполнять алгоритм?
Суть теста - замерить скорость создания/удаления объектов. Рассчёты только для того, чтобы компилятор не соптимизировал.

Apache напал на Oracle и угрожает форкнуть Java

http://www.rsdn.ru/forum/java/4032694.flat.aspx

Теперь будет .NET C# и две жабы, кошерная Premium и опенсорсная, несовместимая от апачей. Интересно, к кому примкнет Google, к апачам или к мерзким проприетарщикам?

> Спецификация - тут, разбирайтесь. ...

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

> Присваивание чего? Все объекты, что создаются - разные. Это тебе не константа. Хочешь проверить - вынеси создание объекта из цикла.

Вообще-то Object не сильно отличается от Object-а. Но чтобы проверить, убедиться, что действительно разные объекты создаются с такой скоростью, и был написан второй кусок кода. И он доказал, что это пиздеж и провокация реальные объекты создаются намного дольше.

Напомню еще раз. Проверялась только фраза:

В жабе выделение небольшого блока памяти занимает порядка 1-3 наносекунды.

> Ну абзац. Выделил массив и создал кучу долгоживущих объектов. Причем объекты, вероятно, уже ушли из зоны Eden.

Это была всего лишь проверка вашего утверждение на практике. Оно оказалось ложным. Или вы в том утверждении забыли сделать какое-то «очевидное» уточнение? Например, «в жабе выделение никому не нужного блока памяти занимает 3 наносекунды»?

Неплохо звучит... Java - это такой язык, в котором даже ничего не делающая операция занимает 3 наносекунды.

Вы все еще будете настаивать, что в том куске кода хоть что-то выделяется? Тогда объясните, почему программа, делающая 1 миллиард «выделений» не занимает даже 200МБ?

Или, может, вы считаете, что присваивание с выделением занимает 8 наносекунд, а присваивание со сложением - 11? Операция выделения быстрее, чем сложение?

Попробуй переписать свой второй пример (тот, что с массивом) на C или C++ и глянь на цифры. Если цифры маленькие - покажи код, я покажу тебе где у тебя ошибка. %)

То есть возражений против того, что в жаве выделение далеко не 3 наносекунды, больше нет?

Напоминает обычную тактику фанатиков. Когда оказывается, что твой выбор не такой хороший, как думалось, начинается «зато у других еще хуже». Ладно, все познается в сравнении. Сравним:

$ cat NewSpeed2.cpp 
#include <sys/time.h>
#include <iostream>

class NewSpeed2
{
public:
  int n;
  NewSpeed2(int n) {
    this->n = n;
  }
};

int main()
{
  int N = 10000000;
  NewSpeed2 *o[N];
  struct timeval start, end;

  gettimeofday(&start, NULL);
  for (int i = 0; i < N; i++)
    o[i] = new NewSpeed2(i);
  gettimeofday(&end, NULL);

  std::cout << ((end.tv_sec-start.tv_sec)*1000000 + end.tv_usec - start.tv_usec)*1000/N << std::endl;

  long debugsum = 0;
  gettimeofday(&start, NULL);
  for (int i = 0; i < N; i++)
    debugsum += o[i]->n;
  gettimeofday(&end, NULL);

  std::cout << ((end.tv_sec-start.tv_sec)*1000000 + end.tv_usec - start.tv_usec)*1000/N << std::endl;
  std::cout << debugsum << std::endl;
  return 0;
}
$ g++ -o NewSpeed2 NewSpeed2.cpp
$ time ./NewSpeed2
129
16
49999995000000

real    0m1.547s
user    0m1.055s
sys     0m0.424s

Получилось примерно в 3 раза быстрее. Где ошибка?