Re: Производительность?
Hello, Novo! Novo wrote: Как говорится, сам себя не похвалишь - никто не похвалит. Ну раз большой специалист, то ты можешь написать правильные тесты с воспроизводимой методикой для различных баз и различных API. Буду ждать. Хочется задоунлоадить и сравнить. А то все слова, слова. Как говорят у нас в Одессе - 96% процентов людей на земле знают как надо делать деньги и только 4% умееют. да пойми ты, синтетические тесты это скучное и никому не интересное дело. Т.е. оно интересно только одной категории разработчиков, которые вообще или пока не понимают, что производительность зависит от того, как написано их приложение. И что никакой тест не даст их приложению ускорения производительности :-) Буду ждать результатов твоих тестов в правильном формате. он если и тестирует, то свой код в FB 2.x :-) Ещё вопросы есть ? Несомненно. А почему ты ведешь себя абсолютно иначе в sourceforge.firebird-devel? Просто два разных человека. Видимо именно там и надо об этом спросить. Ссылку на оригинальную дискуссию обещаю. товарищ! или господин! привыкай к неформальному общению. Лично тебе тут никто ничего не должен. P.S. Поскольку я получил достаточно полное представление об общей культуре русских программистов, в особенности больших специалистов, то дальнейшие дискуссии я буду вести на sourceforge.firebird-devel. Там же жду и анонса правильных тестов. слушай, если ты там будешь такое писать, я тебя буду считать провокатором, который отвлекает разработчиков от их насущных дел. О чем там прямо и напишу. Мол, неудовлетворенный товарищ, который хочет свои амбиции и задачи решить, пытается переложить все это дело на чужие плечи, и т.п. Что весьма недалеко от правды. fb-devel - это конфа по разработке сервера, а не по написанию тестов для 100 различных серверов. Группа поддержки тоже может продемонстрировать свои программистские способности. А то вдруг я смогу наглядно продемонстрировать что SQLITE лучше FB в качестве Embedded Database. Должны же найтись не голословные оппоненты. может хватит пальцы гнуть? Firebird-у абсолютно не нужно никакое соревнование или мерянье с SQLLite. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Производительность?
"Novo" ... > > > > Уважаемый Хорсун Влад, позвольте спросить, а что хамстсво - это > > > единственное, что вы умеете делать? > > > > Да, я большой специалист, а что ? > > Как говорится, сам себя не похвалишь - никто не похвалит. > Ну раз большой специалист, то ты можешь написать правильные тесты с > воспроизводимой методикой для различных баз и различных API. Ты не понял, я нахамить большой специалист. А тут - так, мимо проходил > Буду ждать. См. ниже > Хочется задоунлоадить и сравнить. А то все слова, слова. Как > говорят у нас в Одессе - 96% процентов людей на земле знают как надо > делать деньги и только 4% умееют. А тут не деньги делают. Тут невинным хамят и опускают. Так что ты не туда обратился. Дать тебе правильное направление или сам поймёшь ? > > Хамством я считаю тот формат в котором были результаты сравнения > > яблок с апельсинами. И отвечаю в том же духе > > Прошу прощения за формат результатов не достойный большого > специалиста. Оступился, больше не повторится. Боюсь у тебя тут уже ничего не повторится ;) > Буду ждать результатов твоих тестов в правильном формате. См. ниже > > Ещё вопросы есть ? > > Несомненно. А почему ты ведешь себя абсолютно иначе в > sourceforge.firebird-devel? Просто два разных человека. Видимо именно > там и надо об этом спросить. Ссылку на оригинальную дискуссию обещаю. А ты не заметил, что в firebird-devel не задают идиотские вопросы ? Они все в саппорте живут. И посылают там не меньше чем здесь > P.S. Поскольку я получил достаточно полное представление об общей > культуре русских программистов, в особенности больших специалистов, то Поздравляю > дальнейшие дискуссии я буду вести на sourceforge.firebird-devel. Там Попробуй > же жду и анонса правильных тестов. Группа поддержки тоже может > продемонстрировать свои программистские способности. Яволь ! Все уже построились > А то вдруг я > смогу наглядно продемонстрировать что SQLITE лучше FB в качестве > Embedded Database. Должны же найтись не голословные оппоненты. Нет ! Только не это ! Я застрелюсь > Ждемс. Ещё один зависший в ожидании... -- Хорсун Влад PS Я уже не раз говорил о том, что нахамить можно и в очень вежливой форме, а обращение с Уважаемый и на Вы совершенно не свидетельствует о высокой культуре. Могу ещё напомнить очевидную истину о чужом монастыре и своём уставе
Re: Производительность?
"Alex Cherednichenko" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > =Beginning of the citation== > Comcast Corporation > 1500 Market Street > Philadelphia, PA 19102 > US > =The end of the citation Небоскрёбы небоскрёбы а я маленький такой, то мне страшно, то мне грустно, то теряю я покой (С) :-):-):-)
Re: Производительность?
Привет, Oleg! Вы пишешь 13 апреля 2007: [Sorry, skipped] OL> P.S. Ты случайно не из пиндостана нам сюда буковки царапаешь? OL> Ась? =Beginning of the citation== Comcast Corporation 1500 Market Street Philadelphia, PA 19102 US =The end of the citation -- With best regards, Alex Cherednichenko.
Re: Производительность?
"Novo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > ждать. Хочется задоунлоадить и сравнить. А то все слова, слова. Как > говорят у нас в Одессе - 96% процентов людей на земле знают как надо > делать деньги и только 4% умееют. Я не знаю как у вас в Одессе, а у нас давно есть TPCC/TPCR. Результаты этих тестов публиковались. Причём для достаточного количества серверов. Подробное обсуждениесть на sql.ru. > P.S. Поскольку я получил достаточно полное представление об общей > культуре русских программистов, в особенности больших специалистов, то А теперь уважаемый, за фразу "об общей скультуре русских программистов" бойтесь ;-), ибо в реалии у нас за такое бьют в лицо причём сразу и без разговоров об общечеловеческих ценностях. > смогу наглядно продемонстрировать что SQLITE лучше FB в качестве > Embedded Database. Должны же найтись не голословные оппоненты. Демонстрировть свою тупизну ты можешь в другом месте. Ибо сравнивать жопу с пальцем может только идиот. P.S. Ты случайно не из пиндостана нам сюда буковки царапаешь? Ась?
Re: Производительность?
Привет, Novo! Вы пишешь 13 апреля 2007: N> Как говорят у нас в Одессе - 96% процентов людей на земле знают как надо N> делать деньги и только 4% умееют. А шо у вас у Филадельфии тоже есть Одесса? Не знал... зы: забаньте его уже кто-нить... -- With best regards, Alex Cherednichenko.
Re: Производительность?
Ахтунг, из зоопарка сбежало животное! Особые приметы - очень культурное, знает многом умных букв и умеет пользоваться компьютером! Коваленко Дмитрий. www.ibprovider.com PS. Пятница начилась удачно. По всем пунктам.
Re: Производительность?
On Apr 11, 10:51 am, "Vlad Horsun" <[EMAIL PROTECTED]> wrote: > "Novo" ... > > > Уважаемый Хорсун Влад, позвольте спросить, а что хамстсво - это > > единственное, что вы умеете делать? > > Да, я большой специалист, а что ? Как говорится, сам себя не похвалишь - никто не похвалит. Ну раз большой специалист, то ты можешь написать правильные тесты с воспроизводимой методикой для различных баз и различных API. Буду ждать. Хочется задоунлоадить и сравнить. А то все слова, слова. Как говорят у нас в Одессе - 96% процентов людей на земле знают как надо делать деньги и только 4% умееют. > Хамством я считаю тот формат в котором были результаты сравнения > яблок с апельсинами. И отвечаю в том же духе Прошу прощения за формат результатов не достойный большого специалиста. Оступился, больше не повторится. Буду ждать результатов твоих тестов в правильном формате. > Ещё вопросы есть ? Несомненно. А почему ты ведешь себя абсолютно иначе в sourceforge.firebird-devel? Просто два разных человека. Видимо именно там и надо об этом спросить. Ссылку на оригинальную дискуссию обещаю. P.S. Поскольку я получил достаточно полное представление об общей культуре русских программистов, в особенности больших специалистов, то дальнейшие дискуссии я буду вести на sourceforge.firebird-devel. Там же жду и анонса правильных тестов. Группа поддержки тоже может продемонстрировать свои программистские способности. А то вдруг я смогу наглядно продемонстрировать что SQLITE лучше FB в качестве Embedded Database. Должны же найтись не голословные оппоненты. Ждемс.
Re: Производительность?
"Vlad Horsun" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >Ещё вопросы есть ? Дайте, дайте я ему отвечу... Уважаемый некто под названием Novo. Вся мировая общественность приносит Вам свои извинения по факту употребления Владом буквосочетания "Та ты шо !" в Ваш адрес. Наверно это совершенно безобидная фраза, на Вашем местном наречии означает "Пошёл на х~й", что же Влад не знал фонетических особенностей языка Novо - простим же его.
Re: Производительность?
"Novo" ... > > Уважаемый Хорсун Влад, позвольте спросить, а что хамстсво - это > единственное, что вы умеете делать? Да, я большой специалист, а что ? Хамством я считаю тот формат в котором были результаты сравнения яблок с апельсинами. И отвечаю в том же духе Ещё вопросы есть ? -- Хорсун Влад
Re: Производительность?
Привет, Novo! Вы пишешь 11 апреля 2007: N> Уважаемый Хорсун Влад, позвольте спросить, а что хамстсво - это N> единственное, что вы умеете делать? Юноша, ты ещё пока очень юн и глуп. Первое поправимо. Второе - ой ли.. Прощай навеки! -- With best regards, Alex Cherednichenko.
Re: Производительность?
Уважаемый Хорсун Влад, позвольте спросить, а что хамстсво - это единственное, что вы умеете делать? On Apr 11, 2:42 am, "Vlad Horsun" <[EMAIL PROTECTED]> wrote: > "Novo" ... > > > Для сравнения тесты для SQLITE. > > Для сравнения результаты рядом показывают, а не заставляют читателя > прыгать по тексту десятки раз > > ... > > > При работе с SQLITE процесс занимает порядка 3 Mb, при работе с > > Embedded Firebird процесс занимает порядка 30 мег. > > Та ты шо ! А можно и 300 мег сделать, не знал ? > > -- > Хорсун Влад
Re: Производительность?
"Novo" ... > Для сравнения тесты для SQLITE. Для сравнения результаты рядом показывают, а не заставляют читателя прыгать по тексту десятки раз ... > При работе с SQLITE процесс занимает порядка 3 Mb, при работе с > Embedded Firebird процесс занимает порядка 30 мег. Та ты шо ! А можно и 300 мег сделать, не знал ? -- Хорсун Влад
Re: Производительность?
Вдогонку к своему-же письму. E:\work\tmp\perf_sdb>perf_sdb_test.exe --conn_str="/InterBase_EMB" -- db_name=TES T01.FDB --user_name=test --user_passwd=test Sdb performance tests ... Test INSERT 01. Insert 4000 records. Autocommit. INSERT INTO t1 VALUES(:?, :?, :?) 0.062 sec. Test INSERT 02. Insert 10 records. Inside of a transaction. INSERT INTO t2 VALUES(:?, :?, :?) 2.109 sec. Test INSERT 03. Insert 10 records into an indexed table. Inside of a transac tion. INSERT INTO t3 VALUES(:?, :?, :?) 26.907 sec. Test SELECT 02. Select 100 times without an index. Fetch result. SELECT count(*), avg(b) FROM t2 WHERE b >= :? AND b < :? 0.093 sec. Test SELECT 03. Select 100 times without an index on a string comparison. Fetch result. SELECT count(*), avg(b) FROM t2 WHERE c LIKE :? 0.157 sec. Test INNER JOIN 01. Without an index. Fetch result. SELECT t1.a FROM t1 INNER JOIN t2 ON t1.b = t2.b 0.218 sec. Test CREATE INDEX 01. Run 1 time on an ordered field. CREATE INDEX i2a ON t2(a) 0.266 sec. Test CREATE INDEX 02. Run 1 time on a nonordered field. CREATE INDEX i2b ON t2(b) 0.266 sec. Test SELECT 04. Select 1000 times with an index. Fetch result. SELECT count(*), avg(b) FROM t2 WHERE b >= :? AND b < :? 0.015 sec. Test UPDATE 01. Update 400 times without an index. Inside of a transaction. UPDATE t1 SET b = b*2 WHERE a >= :? AND a < :? 1.704 sec. Test UPDATE 02. Update 4000 times with an index. Inside of a transaction. UPDATE t2 SET b = :? WHERE a = :? 0.562 sec. Test UPDATE 03. Update 4000 times a text value with an index. Inside of a transa ction. UPDATE t2 SET c = :? WHERE a = :? 0.188 sec. Test INSERT from a SELECT 01. Inside of a transaction. INSERT INTO t1 SELECT * FROM t2 0.656 sec. Test INSERT from a SELECT 02. Inside of a transaction. INSERT INTO t2 SELECT * FROM t1 21.547 sec. Test INNER JOIN 02. With index on one side. Fetch result. SELECT t1.a FROM t1 INNER JOIN t2 ON t1.b = t2.b 2.953 sec. Test SELECT 05. Select 100 times with subqueries. Subquery is using an index. Fe tch result. SELECT t1.a FROM t1 WHERE t1.b IN (SELECT t2.b FROM t2 WHERE t2.b >= :? AND t2.b < :?) 2.062 sec. Test DELETE 01. Run 1 time without an index. DELETE FROM t2 WHERE c LIKE '%fifty%' 0.25 sec. Test DELETE 02. Run 1 time with an index. DELETE FROM t2 WHERE a > 10 AND a < 95000 1.688 sec. Test DELETE 03. A big DELETE followed by many small INSERTs. Run 4000 times. Inside of a transaction. DELETE FROM t1 INSERT INTO t1 VALUES(:?, :?, :?) 0.984 sec. Для сравнения тесты для SQLITE. E:\work\tmp\perf_sdb>perf_sdb_test.exe --conn_str="/SQLITE_EMB" -- db_name=test. sqlite Sdb performance tests ... Test INSERT 01. Insert 4000 records. Autocommit. INSERT INTO t1 VALUES(:?, :?, :?) 0.016 sec. Test INSERT 02. Insert 10 records. Inside of a transaction. INSERT INTO t2 VALUES(:?, :?, :?) 0.641 sec. Test INSERT 03. Insert 10 records into an indexed table. Inside of a transac tion. INSERT INTO t3 VALUES(:?, :?, :?) 2.406 sec. Test SELECT 02. Select 100 times without an index. Fetch result. SELECT count(*), avg(b) FROM t2 WHERE b >= :? AND b < :? 6.078 sec. Test SELECT 03. Select 100 times without an index on a string comparison. Fetch result. SELECT count(*), avg(b) FROM t2 WHERE c LIKE :? 9.781 sec. Test INNER JOIN 01. Without an index. Fetch result. SELECT t1.a FROM t1 INNER JOIN t2 ON t1.b = t2.b 159.8 sec. Test CREATE INDEX 01. Run 1 time on an ordered field. CREATE INDEX i2a ON t2(a) 0.937 sec. Test CREATE INDEX 02. Run 1 time on a nonordered field. CREATE INDEX i2b ON t2(b) 0.922 sec. Test SELECT 04. Select 1000 times with an index. Fetch result. SELECT count(*), avg(b) FROM t2 WHERE b >= :? AND b < :? 0.703 sec. Test UPDATE 01. Update 400 times without an index. Inside of a transaction. UPDATE t1 SET b = b*2 WHERE a >= :? AND a < :? 0.563 sec. Test UPDATE 02. Update 4000 times with an index. Inside of a transaction. UPDATE t2 SET b = :? WHERE a = :? 0.109 sec. Test UPDATE 03. Update 4000 times a text value with an index. Inside of a transa ction. UPDATE t2 SET c = :? WHERE a = :? 0.078 sec. Test INSERT from a SELECT 01. Inside of a transaction. INSERT INTO t1 SELECT * FROM t2 1.016 sec. Test INSERT from a SELECT 02. Inside of a transaction. INSERT INTO t2 SELECT * FROM t1 2.875 sec. Test INNER JOIN 02. With index on one side. Fetch result. SELECT t1.a FROM t1 INNER JOIN t2 ON t1.b = t2.b 0.484 sec. Test SELECT 05. Select 100 times with subqueries. Subquery is using an index. Fe tch result. SELECT t1.a FROM t1 WHERE t1.b IN (SELECT t2.b FROM t2 WHERE t2.b >= :? AND t2.b < :?) 21.391 sec. Test DELETE 01. Run 1 time without an index. DELETE FROM t2 WHERE c LIKE '%fifty%' 0.141 sec. Test DELETE 02. Run 1 time with an index. DELETE FROM t2 WHERE a > 10 AND a < 95000 1.828 sec. Test DELETE 03. A big DELETE followed by many small INSERTs. Run 4000 times. Inside of a transaction. DELETE FROM t1 INSERT INTO t1 VALUES(:?, :?, :?) 0.093 sec. При работе с SQLITE процесс занимает порядка 3 M
Re: Производительность?
У меня есть тесты, сделанные по образцу SQLite. Сделаны они были для тестирования различных API. Написано все на C++. На текущий момент можно потестировать: "/SQLITE" "/SQLITE_EMB" "/ADO/Microsoft.Jet.OLEDB.4.0" "/ODBC/Microsoft Access Driver (*.mdb)" "/InterBase" (Firebird 1.5) "/InterBase_EMB" (Firebird Embedded 1.5) "/ADO/sqloledb" "/ODBC/SQL Server" "/ODBC/SQL Native Client" "/ODBC/FreeTDS" Можно к этому еще добавить ORACLE, MySQL 3.2, PostgreSQL, DB2, Sybase в течении какого-то времени. Я могу запостить результаты тестов, а могу и сами тесты (для Windows) -- Sergey Sikorskiy cDima wrote: > Добрый день, > > Я хочу понять, что быстрее, встроенный в .Net XML-средства хранения > информации на жётском диске, или встроенная Firebird-база. > > Спасибо, > Дмитрий Садаков.
Re: Производительность?
Boulitchev Aleksey wrote: у нас собираются агрегаты на документы, насколько я знаю, у Деда тоже. Угумс. -- Regards. Ded.
Re: Производительность?
Count мы победили агрегатными триггерами :) Блохи на моей голове вздрогнули от воспоминаний о багах, которые несут такие триггеры :) это всего лишь еще один способ блокировки одновременных писателей. у нас собираются агрегаты на документы, насколько я знаю, у Деда тоже. -- Булычев Алексей http://www.stella-npf.ru
Re: Производительность?
Sergey Mereutsa wrote: Зуб даешь? А то! З.Ы. Что вы там такого в hEAD намутили с readline, что под линухом оно пытается сделать rm -f readline readline.exe и обламывается? И зачем там .exe? ;-) Вопрос не по адресу :-) -- Дмитрий Еманов
Re: Производительность?
> Count мы победили агрегатными триггерами :) Блохи на моей голове вздрогнули от воспоминаний о багах, которые несут такие триггеры :) Коваленко Дмитрий
Re: Производительность?
Sergey Mereutsa wrote: 2) Меделенный count() как без так и с условием - по сравнению именно с Постгри. Тут я ничего сказать не могу, потому что Постгри тоже версионник, но count() там реально быстрый. Как он там реализован хз, но факт - сам видел. Не верю (с) Функция count там устроена абсолютно аналогично. И в их форумах так же регулярно просят ее ускорить, чтобы не работала натуралом. Можешь посмотреть тамошний to-do список. Единственное доступное мне объяснение - либо скан таблицы там работает быстрее, либо страничный кеш более эффективнее. -- Дмитрий Еманов
Re: Производительность?
Hello, All! Dmitri Kuzmenko wrote: The Open Source Database Benchmark - http://osdb.sourceforge.net/ Например http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison , сравнивание firebird 1.5 и SQLite по разным типам запросов. какой смысл сравнивать СЕРВЕР со встраиваемым однопользовательским движком??? кстати. любой мудрец понимает, что однопользовательский движок будет практически всегда быстрее сервера. Потому что в однопользовательском движке не надо думать про многопользовательскую работу. что и написано по упомянутой ссыке SpeedComparison. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Производительность?
Hello, cDima! cDima wrote: The Open Source Database Benchmark - http://osdb.sourceforge.net/ Например http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison , сравнивание firebird 1.5 и SQLite по разным типам запросов. какой смысл сравнивать СЕРВЕР со встраиваемым однопользовательским движком??? Что если ты выполнишь теже запросы с другими embedded-средствами и они сработают намного медленее, то firebird лучше своих конкурентов и его можно использовать в продукте. Я бы не хотел встраивать firebird в свою программу чтобы потом узнать, что firebird страшный тормоз. 1. такого обычно не бывает 2. влияние оказывает архитектура сервера. Поскольку FB версионник, это надо принимать во внимание, и сравнивать его с версионниками. Всякие SQLLite надо сравнивать с такими же однопользовательскими движками. 3. обычно читают перечень функциональности, по нему определяются 4. Фокспро в однопользовательском режиме быстрее всех. И что? и т.д. Не популярен интерес к benchmark-ам среди вас, понятно. да вообще бенчмарки среди специалистов по СУБД не популярны. это только начинающие ищут бенчмарки. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Производительность?
> > Исследовательских статей на эту > > тему вы *совсем* не видели? > >Неее, этот чукча - их писатель. Бугыгы. Пацталом. Коваленко Дмитрий.
Re: Производительность?
> c> Отличный ответ, спасибо. LINQ сильно бы облегчил жизнь, но пока его > c> нет будем использовать firebird. > > и и к чему тогда был этот топик, если всеравно уже давно выбрал firebird? Не, ну ты чего? Никак не догонишь? А как же понты? Коваленко Дмитрий.
Re: Производительность?
Привет Sergey Mereutsa Не популярен интерес к benchmark-ам среди вас, понятно. А ты не задумывался, _почему_ нормальные пацаны _никогда_ бенчмарками не меряюццо? А вот подумай... IIRC Ковязин мерял разные серевра для TPC-C. Наверное народ не понимает что они хотят от бенчмарка. WBR Evgeny Peutilin.
Re: Производительность?
c> Отличный ответ, спасибо. LINQ сильно бы облегчил жизнь, но пока его c> нет будем использовать firebird. и и к чему тогда был этот топик, если всеравно уже давно выбрал firebird? -- С уважением Кочмин Александр Firebird Foundation associate member #257
Re: Производительность?
> Если данные помешаются в доступную физическую память, сохранение и > загрузка с диска делаются нечасто, не нужно делать безумные > многокритериальные запросы с сортировкой и группировкой - xml > достаточно. Десериализовал в память, покрутил как хочешь, сериализовал > обратно. Ну и объекты сложной структуры обрабатывать и хранить проще. Именно, и пока все данные помещаются в память мы и не задумывались о продуктивности, всё летало. Сейчас количество данных увеличится и вопрос станет ребром. > Если же нужны сложные отчеты - LINQ .NET-овский вроде еще не вышел, а > sql сразу намного упрощает жизнь. Большие объемы данных(больше чем > физическая память) сервер обрабатывает более эффективно (индексы и > прочая оптимизация). Ну и опять же - скажут сделать > многопользовательскую версию программы - опять приходим к серверу. Отличный ответ, спасибо. LINQ сильно бы облегчил жизнь, но пока его нет будем использовать firebird. Спасибо, Дмитрий Садаков
Re: Производительность?
> > Вы совсем не видили статьи мудрецов с правильно поставленными > > экспериментами для анализа скорости Firebird? > а вы вообще такие статьи в отношении других серверов видели? The Open Source Database Benchmark - http://osdb.sourceforge.net/ Например http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison , сравнивание firebird 1.5 и SQLite по разным типам запросов. (посмотрите Test 6: INNER JOIN without an index, любопытный результат) http://forums.devshed.com/firebird-sql-development-61/benchmarks-63316.html - ветка где человек искал примерно тоже самое и не нашёл. > Что, например, покажет, если я сообщу о скорости select count > по 2-гиговой таблице на своей машине? О том что я мудрец, > или что у меня комп плохой или хороший? Что если ты выполнишь теже запросы с другими embedded-средствами и они сработают намного медленее, то firebird лучше своих конкурентов и его можно использовать в продукте. Я бы не хотел встраивать firebird в свою программу чтобы потом узнать, что firebird страшный тормоз. Не популярен интерес к benchmark-ам среди вас, понятно. Спасибо, Дмитрий
Re: Производительность?
cDima wrote: Исследовательских статей на эту тему вы *совсем* не видели? Неее, этот чукча - их писатель. -- Regards. Ded.
Re: Производительность?
Hello, cDima! cDima wrote: "Возьми данные, залей, попробуй." - я не первый и не последний буду засекать время запросов от Firebird. Исследовательских статей на эту тему вы *совсем* не видели? ну я исследователь и мудрец. что исследовать-то надо? статьи на ibase.ru, в разделе документация, тесты. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Производительность?
Hello, cDima! cDima wrote: Вы совсем не видили статьи мудрецов с правильно поставленными экспериментами для анализа скорости Firebird? а вы вообще такие статьи в отношении других серверов видели? К чему этот сферический конь в вакууме? на ibase.ru есть статьи с тестами. например, бэкапа, массового update, вставки по insert/update, но это специфика. Что, например, покажет, если я сообщу о скорости select count по 2-гиговой таблице на своей машине? О том что я мудрец, или что у меня комп плохой или хороший? Можно варьировать тип запроса, размер таблицы и прочее, не хотелось бы это делать на коленке. фигню вы пишете. такими вещами занимаются только если действительно производительности не хватает. А за пару секунд никто не борется. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Производительность?
On 6 апр, 14:56, "Horsun Vlad" <[EMAIL PROTECTED]> wrote: > "Yurij" ... > > Если же нужны сложные отчеты - LINQ .NET-овский вроде еще не вышел, а > > sql сразу намного упрощает жизнь. > А вот скажи - чем LINQ принципиально отличается от embedded sql ? Embedded sql выполняет запросы к серверу, а LINQ, кроме того, может обрабатывать множества объектов, хранящиеяся в памяти(списки, коллекции, итд). Embedded sql обрабатывается препроцессором, LINQ - компилятором. LINQ более близок к функциональному программированию - автоматически выводимые типы результата, лямбда-выражения, функции, передаваемые в качестве данных.
Re: Производительность?
"Yurij" ... > Если же нужны сложные отчеты - LINQ .NET-овский вроде еще не вышел, а > sql сразу намного упрощает жизнь. А вот скажи - чем LINQ принципиально отличается от embedded sql ? -- Хорсун Влад
Re: Производительность?
DL>> Можно варьировать тип запроса, размер таблицы и прочее, не хотелось бы DL>> это делать на коленке. DL> DL> Этого я не понял. Чем коленка не угодила? :-))) тут ведь весь вопрос в том, чья это коленка, а топикстартер этот момент умалчивает. -- С уважением Кочмин Александр Firebird Foundation associate member #257
Re: Производительность?
On Fri, 06 Apr 2007 13:52:10 +0400, cDima <[EMAIL PROTECTED]> wrote: > я не первый и не последний буду > засекать время запросов от Firebird. Мои выполняются по-разному, от 1 мс до 20 минут. В зависимости от ... эээ ... куда тут можно залить архив со списком зависимостей? -- Сергей Смирнов.
Re: Производительность?
МГ> МГ> МГ> "Alexandr Kochmin" <[EMAIL PROTECTED]> МГ> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] МГ>> МГ>> ну вот я исследовал. 15 получилось. МГ>> МГ> Ну вот, тоже мне исследователь, 17 должно быть. И вааще, чего МГ> аппаратную конфигурацию не приводишь? Монитор у тебя какой? ой точно. 17 получилось. И монитор как раз 17'' совпедение? -- С уважением Кочмин Александр Firebird Foundation associate member #257
Re: Производительность?
On 6 апр, 12:52, "cDima" <[EMAIL PROTECTED]> wrote: > "Возьми данные, залей, попробуй." - я не первый и не последний буду > засекать время запросов от Firebird. Исследовательских статей на эту > тему вы *совсем* не видели? Если данные помешаются в доступную физическую память, сохранение и загрузка с диска делаются нечасто, не нужно делать безумные многокритериальные запросы с сортировкой и группировкой - xml достаточно. Десериализовал в память, покрутил как хочешь, сериализовал обратно. Ну и объекты сложной структуры обрабатывать и хранить проще. Если же нужны сложные отчеты - LINQ .NET-овский вроде еще не вышел, а sql сразу намного упрощает жизнь. Большие объемы данных(больше чем физическая память) сервер обрабатывает более эффективно (индексы и прочая оптимизация). Ну и опять же - скажут сделать многопользовательскую версию программы - опять приходим к серверу.
Re: Производительность?
"Alexandr Kochmin" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] ну вот я исследовал. 15 получилось. Ну вот, тоже мне исследователь, 17 должно быть. И вааще, чего аппаратную конфигурацию не приводишь? Монитор у тебя какой? With b/r. Gleb.
Re: Производительность?
c> Вы совсем не видили статьи мудрецов с правильно поставленными c> экспериментами для анализа скорости Firebird? c> Можно варьировать тип запроса, размер таблицы и прочее, не хотелось бы c> это делать на коленке. нифига непонятно чего тебе надо-то. Сформулируй нормально сначала, потом поймешь, что давно бы уже сам пару тестов сделал и все увидел бы. -- С уважением Кочмин Александр Firebird Foundation associate member #257
Re: Производительность?
> Если бы XML был настолько совершенен, то не было бы MS SQL > например. :-))) > Тут пока и сравнивать нечего. > Дмитрий Зря я упоминул XML. =) Не спорю, но для мелких объемов (300 rss feed'ов, каждый по 30 элементов, в целом 1 элементов в базе) не требуется термоядерный Firebird. Вы совсем не видили статьи мудрецов с правильно поставленными экспериментами для анализа скорости Firebird? Можно варьировать тип запроса, размер таблицы и прочее, не хотелось бы это делать на коленке. Спасибо, Дмитрий
Re: Производительность?
ну вот я исследовал. 15 получилось. c> c> "Возьми данные, залей, попробуй." - я не первый и не последний буду c> засекать время запросов от Firebird. Исследовательских статей на эту c> тему вы *совсем* не видели? -- С уважением Кочмин Александр Firebird Foundation associate member #257
Re: Производительность?
"Возьми данные, залей, попробуй." - я не первый и не последний буду засекать время запросов от Firebird. Исследовательских статей на эту тему вы *совсем* не видели? On Apr 6, 10:35 am, Dmitri Kuzmenko <[EMAIL PROTECTED]> wrote: > Hello, cDima! > > cDima wrote: > > Подскажите обзоры производительности embedded-версии Firebird DB, > > последних версий. Можете подсказать статьи или ресурсы, плиз? Язык не > > важен. > > Embedded это вариант сервера. соответственно производительность та > же самая. потом, что значит "производительность"? Возьми данные, > залей, попробуй. > > -- > Dmitri Kouzmenko,www.ibase.ru, (495) 953-13-34
Re: Производительность?
Hello, cDima! cDima wrote: Подскажите обзоры производительности embedded-версии Firebird DB, последних версий. Можете подсказать статьи или ресурсы, плиз? Язык не важен. Embedded это вариант сервера. соответственно производительность та же самая. потом, что значит "производительность"? Возьми данные, залей, попробуй. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Производительность?
Hello cDima, Friday, April 6, 2007, 1:12:12 AM, you wrote: c> Добрый день, c> Особенно интересует случай с примерно 1000-100 элементов в Если ты будешь сериализовать дата сеты то загрузки 100 можешь не дождаться :))) c> таблице, запросы на выборки по LIKE "Somethin%" с сортировкой по int- c> полю. А можеть нативные обьекты, бинарная сериализаци и грузить все сразу? Тема Дня: Удаpим "Пpогpессом" по оpбитальной станции "Миp"! До не скорой встречи в аду, Maxmailto:[EMAIL PROTECTED]
Re: Производительность?
Если бы XML был настолько совершенен, то не было бы MS SQL например. :-))) Тут пока и сравнивать нечего. Дмитрий
