> Вот пример такой работы: Point A(0,0); Отличная работа. Теперь а) посмотрите что из этого сделал современный компилятор для современного процессора; б) создайте пару миллионов таких объектов, передайте привет вашему стеку.
А если серьезно, то обсуждать экономию пяти наносекунд в микробенчмарке с бесконечным циклом - занятие столь же утомительное сколь и малопродуктивное.
> В большинстве "вменяемых альтернатив" на стеке создается только ссылка, а сам объект размещается в более медленной куче. В более это на два порядка.
Это очень страшно выглядит только пока вы остаетесь в плену стереотипов Си-мышления образца 1970 года. Примерно по этой же причине вас в LISP и Scheme пугают скобочки - потому что вы помните что в Си такое количество скобочек означает дикую лапшу, а не сами по себе.
>The first thing to understand about OCaml is that allocation, in particular short-lived allocations, are much cheaper than you're used to from languages like C# and Java --- allocating a block on the minor heap requires only three instructions, and collection of those objects is very inexpensive if they don't survive to move to the major heap. So the need to allocate lots of short-lived objects is less of a concern than you'd naively imagine.
>That said, if you want to build very high-throughput applications that can process millions of transactions a second, you to need to avoid allocation, particularly long-lived allocations that end up on the major heap. Jane Street's Core library (which is used throughout Real World OCaml) provides tools for creating pooled objects for just this kind of use-case.
>http://www.infoq.com/articles/real-world-ocaml-interview
>В большинстве "вменяемых альтернатив" вместо него linked list со временем доступа O(n).
>В особо "вменяемых альтернативах" объекты представляют собой hash таблицы и время доступа к полю объекта в массиве составляет O(n^2)
Сложно угадать о каких именно существующих в вашем воображении альтернативах вы говорите. Может быть, о Javascript? Давайте о чем-нибудь менее удобном для избиения и более вменяемом, о том же OCamle, например.
>В приведенных вами "вменяемых альтернативах" это не работает.
Но воображение у вас хорошее. Чего о памяти, к сожалению, не скажешь.
>В "вменяемых альтернативах" мы читаем файл побайтово и пытаемся десерелиазовать байты в типы. Давайте меняться? Вы мне парсер типа файла Х на "вменяемых" языках я вам 20 на невменяемых.
Давайте. Вот вам парсер - https://code.google.com/p/bitstring/source/browse/trunk/exam...
С вас такой же на С++, без include pcap.h, разумеется - это ведь просто пример.
Формат здесь - http://wiki.wireshark.org/Development/LibpcapFileFormat
Потом сравните скорость работы, задумайтесь, сделайте выводы самостоятельно.
Для разминки можете сделать простое упражнение - написать на Си разбор простейшего формата - 6 битный счетчик n, за ним - целое число размером n бит (битов в нём может быть от 1 до 64)
На OCaml это выглядит так:
>let bits = Bitstring.bitstring_of_file "input.data" in
>bitmatch bits with
>| { n : 6;
> data : n+1 } -> data
Библиотека очень простая, в Си вынесен кусочек с полутора маленькими fastpath-частными случаями.
В качестве более общего примера можете посмотреть сюда - http://www.ffconsultancy.com/languages/ray_tracer/comparison...
