В данном случае разрыв между PostgreSQL и MongoDB почти в 20 раз.
Не думаю, что простым fsync = off это можно было исправить, учитывая использование SSD.
А мне кажется тут может быть интересные результаты. Во всяком случае для меня они были бы полезны.
Что же касается pgpool, то любая СУБД не любит новые соединения. Тот же SQLite в рамках одного соединения дает прирост в 1,5 раза на тех же операциях.
Но для пострги это особоно плохо.
В данном же случае используется самый типовой сценарий использования — каждый запрос открывает свое соединения БД.
Работаю с Python, Ruby а на php c Symphony и везде f,s,wcgi. Со скриптами которые дёргались каждый раз, сталкивался только году в 2003 и они были на Perl. Не уверен что это прям самый типовой варинат… по этому было бы здорово сделать то же самое но уже без переоткрытия СУБД каждый раз. :)
Для того, чтобы устроить действительно честное сравнение надо закупить пяток полноценных серверов, под каждую СУБД отдать один и найти грамотных специалистов. Чтобы настройки сделали — максимум скорости, максимум надежности, компромисс.
А потом и устраивать стресс-тесты, в том числе с неожиданными перезагрузками (и считать общий downtime, учитывая «поднятие» «битой» БД).
Вот тогда бы — да, сравнение так сравнение )
Ваш вариант вполне хорош, только вы ведь допиливали SQLite (многопоточная работа и т.д.), а остальные взяли как есть. Просто после таких обзоров очень трудно людям втолковать, что всё настроено не было толково. :)
Если сравнивать постгрес и монго можно было бы в настройках поставить fsync = off, интересно что бы вышло…
И ещё, я смотрю вы каждый раз создаёте новое соединение, а postgres это не любит, нужно либо использовать пулинг (pgpool или что по проще) или же переписать тест на client/server и соеденить апач с вашим приложением по scgi/fcgi/wsgi…
Если проект успешно использует mingw и в качестве редактора/IDE что то другое, то нет не помогает в задаче скомпилировать проект. Но вообще вы путаете тёплое с мягким. Причины использования VS и вашего инструмента различны, это совсем разного класса ПО.
Тут скорее другая аналогия: народ пропалывает грядки вручную, а вы предлагаете куртую и сложную технику для этого. Проблема не в том, что техника плоха или есть лучше конкуренты проблемы в том, что народ в принципе плохо смотрит на любую технику.
Если бы выбор был между инструментом 1 и вашим инструментом 2 который лучше то вопросов нету. Но выбора тут такого нету и он находится в другой плоскости.
Им бы начать по полной использовать те инструменты, что у них есть… и по больше времени на QA тратить.
Видимо пора новой технологии не основанной на DOM и html. С одной стороны веб приложения (и всякие single-page) вещь нужная с другой стороны, строя эти приложения по верх старых технологий получаем химеру.
Нет конечно, но внедрение чего то должно быть обоснованно как логически так и экономически.
Каков будет эффект от внедрения вашего продукта если они уже используют много чего, но продолжают пропускать -Wall?
Видимо все их усилия не очень хорошо окупаются. Почему? Вот это и есть вопрос. Судя по тому, что не исправлены стандартные предупреждения gcc то либо у них нету времени на вылизывание кода (тесты проходит и ладно), либо они в целом этим не занимаются.
создания специальных инструментов для поиска ошибок
занимается отдельный отдел, который хорошо себя пиарит.
Я не утверждаю всё выше написанное, это только догадки. А вы думаете это всё потому, что их инструменты плохи и они просто не видят всех этих ошибок?
Отлично. Вот только вопрос, почему тогда я нашел эту ошибку? :)
Быть может, мы делаем что-то лучше?
1. Видимо народ не особо смотрит на ворнинги при -Wall
2. Безусловно вы делаете, что то лучше иначе не было бы в вас смысла. К тому же вы узкоспециализированный инструмент и вы можете «бить в одну точку»…
Думаю, у некоторых от этой фразы будет истерический смех.
Если вы про то, что гугл и так использует Valgrind то я знаю — видимо мало смотрят. Если вы про то, что Valgrind находит мало ошибок — достаточно, коль даже их пропускают. Лучше поясните причину смеха этих «некоторых».
1. А где баг репорты в проекте хромиум? code.google.com/p/chromium/issues/list (может по этому и не пишут вам)
2. Проверки типа «V547 Expression '0 > * busnum' is always false.» может выполнять и gcc или llvm.
3. Судя по ошибками они в целом плохо изучают код, могли бы тем же Valgrind помучать хотя бы.
4. Как я вижу, большинство ошибок не в самом хромиуме, а во всяких инкапсулированных библиотеках. Благо хоть WebKit они мучают без оглядки на Apple…
Ну вот кто то великолепно всё решает и без этих тулс и подходов. :) На вкус и цвет все фломастеры разные.
Я вот пока даже Stylus/LESS не смог нигде на продакшене применить, хотя трогал и даже нравилось. ИМХО время вас рассудит, слишком это свежие технологии.
А я так искал какой регистр отвечает на моей бывшей GeForce9600GT за обороты вентиляторы… в итоге нашёл. :) Увы тогда проекту nouveau это было не нужно, только nvclock вроде добавил.
Хотя нет, таким способом я много чего делал…
Я сам не знаю какой толк но альтернатива по сути тогда только одна — заткнуться и молчать. Моё програмерское естество хочет хоть, что то сделать для защиты своих прав и здравого смысла.
А мне кажется тут может быть интересные результаты. Во всяком случае для меня они были бы полезны.
Но для пострги это особоно плохо.
Работаю с Python, Ruby а на php c Symphony и везде f,s,wcgi. Со скриптами которые дёргались каждый раз, сталкивался только году в 2003 и они были на Perl. Не уверен что это прям самый типовой варинат… по этому было бы здорово сделать то же самое но уже без переоткрытия СУБД каждый раз. :)
Ваш вариант вполне хорош, только вы ведь допиливали SQLite (многопоточная работа и т.д.), а остальные взяли как есть. Просто после таких обзоров очень трудно людям втолковать, что всё настроено не было толково. :)
И ещё, я смотрю вы каждый раз создаёте новое соединение, а postgres это не любит, нужно либо использовать пулинг (pgpool или что по проще) или же переписать тест на client/server и соеденить апач с вашим приложением по scgi/fcgi/wsgi…
Тут скорее другая аналогия: народ пропалывает грядки вручную, а вы предлагаете куртую и сложную технику для этого. Проблема не в том, что техника плоха или есть лучше конкуренты проблемы в том, что народ в принципе плохо смотрит на любую технику.
Если бы выбор был между инструментом 1 и вашим инструментом 2 который лучше то вопросов нету. Но выбора тут такого нету и он находится в другой плоскости.
Им бы начать по полной использовать те инструменты, что у них есть… и по больше времени на QA тратить.
Каков будет эффект от внедрения вашего продукта если они уже используют много чего, но продолжают пропускать -Wall?
занимается отдельный отдел, который хорошо себя пиарит.
Я не утверждаю всё выше написанное, это только догадки. А вы думаете это всё потому, что их инструменты плохи и они просто не видят всех этих ошибок?
1. Видимо народ не особо смотрит на ворнинги при -Wall
2. Безусловно вы делаете, что то лучше иначе не было бы в вас смысла. К тому же вы узкоспециализированный инструмент и вы можете «бить в одну точку»…
Если вы про то, что гугл и так использует Valgrind то я знаю — видимо мало смотрят. Если вы про то, что Valgrind находит мало ошибок — достаточно, коль даже их пропускают. Лучше поясните причину смеха этих «некоторых».
2. Проверки типа «V547 Expression '0 > * busnum' is always false.» может выполнять и gcc или llvm.
3. Судя по ошибками они в целом плохо изучают код, могли бы тем же Valgrind помучать хотя бы.
4. Как я вижу, большинство ошибок не в самом хромиуме, а во всяких инкапсулированных библиотеках. Благо хоть WebKit они мучают без оглядки на Apple…
Я вот пока даже Stylus/LESS не смог нигде на продакшене применить, хотя трогал и даже нравилось. ИМХО время вас рассудит, слишком это свежие технологии.
Хотя нет, таким способом я много чего делал…