По-моему, это совершенно безумная и бесполезная вещь для мажоров, которые всё ещё могут купиться на бренд. Ну зачем нормальному человеку, будь то программист, офисный работник или геймер, такая клавиатура? Он всё равно во время пользования компьютером на неё не смотрит. Она хоть от чая защищена? Лучше бы сделали действительно идеально удобную, не заедающую, бесшумную, красивую клавиатуру, с нормальными олеофобными кнопками, в том числе с адекватными кнопками insert/delete/pgup/pgdn, с промежутками между группами F-кнопок и без дурацкого удлинённого расстояния между ними и первым рядом символов.
По сути, в postgres есть такой замечательный тип данных, как JSON (а так же ARRAY), в котором тоже можно хранить свойства товаров, и даже строить индексы по их элементам. По поводу преимущества при вставке — попробуйте использовать prepared statements, чтобы не парсить sql запрос каждый раз. Часто на это уходит больше половины времени обработки запроса. Кстати, тестируя вставку в postgres, были ли настройки файловой синхронизации аналогичны mongo? По умолчанию mongo настроена на производительность, а postgres — на целостность данных. Какие настройки fsync и synchronous_commit вы используете в postgres при тестах?
Во-первых странно, почему для тестов pg использовался sql-файл, а не нормальное клиентское соединение с prepared statements. И какой формат вставки был использован, INSERT или COPY?
Во-вторых, в любой нормальной системе на базовые запросы ставятся индексы, и в первую очередь интересны тесты на производительность выборок с индексами.
В-третьих, хотел бы посмотреть на сравнение скоростей транзакций pg и двухфазных коммитов mongo при выполнении какой-нибудь простейшей операции перемещения значения между коллекциями/таблицами в условиях racing condition, поскольку почти любая система неизбежно с ними сталкивается в процессе своего развития. Мы ведь думаем о выборе субд для проекта, глядя в будущее, верно?
Не совсем понял, причем тут классы и их «оверхедное» подключение? Кэш байткода включается элементарной установкой кэшера, например php-apc, без вмешательства в код проекта, и может являться одним из условий запуска проекта, наряду с правильной версией php, бд, и вебсервером.
Стало интересно, написал тест для конкретного случая взятия длины из строки и из замыкания. Как видно, зависимость весьма незначительная и непредсказуемая, и производительность больше зависит от версии v8 и платформы, чем от способа обращения к переменной. Результаты для разных браузеров не рассматриваю в контексте описанного случая (серверный js). Наверняка будут другие результаты, особенно для ие. jsperf.com/length-in-functioin-params
Вот еще тест с пустыми телами цикла, без кеширования работает быстрее (на v8) jsperf.com/browser-diet-cache-array-length
В целом, единственная настоящая проблема того решения — это то, что пробег по строке в регулярке работатет вдвое медленнее, чем посимвольно в цикле, с этим согласен.
Можно и одной, если первая не нужна в другом месте. По поводу length — у меня на тестах фактор отрицательный, например по этому jsperf.com/fastest-array-loops-in-javascript/56 быстрее всего работает for (var i = 0; i < arr.length; i++). Почему он должен быть быстрее, если length — это простое свойство у объекта, обращение к свойству медленнее, чем к аргументу функции?
Ага, понятно в чем дело, я бы тоже так подумал при первом взгляде. Но тут дело в том, что некоторые выводы не очевидны.
1) Откуда мысль о том, что проход шаблона реплейсом должен быть обязательно тормозным? Регулярки — весьма быстрая компилируемая штука, их скорость зависит в основном от логики. С другой стороны, циклы тоже хорошо оптимизируются. На деле charAt действительно оказывается быстрее, но не на порядки.
2) Передача параметров в тестах оказалась быстрее, чем обращение к ним по замыканию.
3) Извлечение length — крайне быстрая операция, это простое обращение к переменной, а не вычисление длины null-terminated строки.
4) Вынос вложенных функций за пределы не дал никакого прироста производительности, компилятор оказался не настолько глуп.
Сейчас настало такое время, что вся школьная библиотека может легко уместиться на ладони. Разумеется, если кто-то позаботился об оцифровке. Поэтому ценность архивов бумажных книг, библиотек, домашних полок — уменьшается, но не пропадает, пока существуют люди, для которых цифровые средства недоступны. Можно найти и художественно оформленные книги, где важна не только информация, но сама книга, переплёт, бумага, это отдельный случай. Самое главное — не потерять информацию, написанную в книгах. Все без исключения книги заслуживают того, чтобы хранить их цифровую копию, просто потому что это чей-то труд, написанный с какой-то целью, начиная от удовлетворения своих творческих потребностей и заканчивая политической и сектантской пропагандой. Этот труд может быть кем-то воспринят, изучен, возможно в далёком будушем, так как мы сейчас изучаем «Молот ведьм». Уничтожать их безвозвратно, основываясь на своих взглядах на правильность и пригодность материала — несправедливо.
Хотелось бы увидеть описание используемых технологий, особенно серверных (игра же вроде онлайновая?). А ещё принципы и формулы из геймдизайна, почему они именно такие, и как к ним пришли. И да, арт какой-то слишком уж вульгарный, при виде такой игры сразу возникает ощущение, что меня хотят обмануть, и вот-вот откроется окно с покером и рулеткой.
Я не рекомендую этот способ, если кто не так понял, а добавляю в копилку тестов по поводу производительности регулярных выражений в подобного рода генераторах, для частного случая посимвольного глобального реплейса с калбэком. 300 тысяч циклов по 10 символов проходят в среднем за секунду, что примерно вдвое медленнее для v8, чем описанные результаты 4, 5.
Кроме того, помимо уже привычных датчиков появится датчик, который следит за силой сжатия устройства. Если честно не очень понимаю как он будет работать и для чего, если кто знает, просьба рассказать в чем его соль.
Выдавать разную контекстную рекламу в зависимости от степени нервного напряжения и характера пользователя, конечно же. :)
Для генерации случайных строк точного размера из строго определённого набора символов я пользовался такой штукой:
function randomSymbol(symbols) {
return symbols.substr(Math.random()*symbols.length, 1);
}
function randomString(sample, symbols) {
return sample.replace(/ /g, function () {
return randomSymbol(symbols);
});
}
console.log(randomString(' ', '12345'));
Скорость пропорциональна длине генерируемой строки, почти не зависит от набора символов. Для строк из 10 символов примерно в 5 раза медленнее, чем у простого toString(36), что вполне достаточно для тестов. На nodejs 0.10.17 c2d 1.8 в среднем 3500 мс против 660 мс на миллионе вызовов.
Во-вторых, в любой нормальной системе на базовые запросы ставятся индексы, и в первую очередь интересны тесты на производительность выборок с индексами.
В-третьих, хотел бы посмотреть на сравнение скоростей транзакций pg и двухфазных коммитов mongo при выполнении какой-нибудь простейшей операции перемещения значения между коллекциями/таблицами в условиях racing condition, поскольку почти любая система неизбежно с ними сталкивается в процессе своего развития. Мы ведь думаем о выборе субд для проекта, глядя в будущее, верно?
jsperf.com/length-in-functioin-params
jsperf.com/browser-diet-cache-array-length
В целом, единственная настоящая проблема того решения — это то, что пробег по строке в регулярке работатет вдвое медленнее, чем посимвольно в цикле, с этим согласен.
1) Откуда мысль о том, что проход шаблона реплейсом должен быть обязательно тормозным? Регулярки — весьма быстрая компилируемая штука, их скорость зависит в основном от логики. С другой стороны, циклы тоже хорошо оптимизируются. На деле charAt действительно оказывается быстрее, но не на порядки.
2) Передача параметров в тестах оказалась быстрее, чем обращение к ним по замыканию.
3) Извлечение length — крайне быстрая операция, это простое обращение к переменной, а не вычисление длины null-terminated строки.
4) Вынос вложенных функций за пределы не дал никакого прироста производительности, компилятор оказался не настолько глуп.
Скорость пропорциональна длине генерируемой строки, почти не зависит от набора символов. Для строк из 10 символов примерно в 5 раза медленнее, чем у простого toString(36), что вполне достаточно для тестов. На nodejs 0.10.17 c2d 1.8 в среднем 3500 мс против 660 мс на миллионе вызовов.