Здравствуйте, CEMb, Вы писали:
CEM>Здравствуйте, Философ, Вы писали:
Ф>>Я ради эксперимента писал собственные контейнерные типы (напр. LinkedList), как для .Net так и Delphi. Ф>>Почти каждый раз получалось медленнее аналогов. Иногда чуть-чуть, а иногда очень заметно. Ф>>Искал причины, отлаживал, дорабатывал...
CEM>И? Получилось же?
Я не буду отвечать на этот вопрос. Я это делал не для того, чтобы получилось.
CEM>Меня настораживают два слова тут: Delphi & .Net Всё что на них пишется, работать быстрее не может по умолчанию (извините, не удержался).
"быстрее, чем что?" — это должен быть основной вопрос. я говорил об аналогах для тех же Delphi и .Net.
CEM>Потому что всё что я писал, ради интереса или нет, работало вроде быстрее. Или удобнее. Вобщем, не зря начинал.
Я тоже не зря начинал. Уж поверьте!
Кстати, ТС таки бы посоветовал всё же писать свою СУБД
Ф>>Часто, при аналогичной алгоритмов проигрывал в скорости чуть-чуть (секунда — полторы на миллион операций). Ф>>Пробовал писать свой мэнеджер памяти (начинал писать)... Ф>>Пришёл к выводу, что это пустая трата времени (в большинстве случаев). CEM>Я бы ещё сюда добавил, что готовые решения, как правило, отлажены хорошо. А свой код ещё погонять надо...
Практика показала, что "готовые решения" тоже желательно тестировать.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, YuriKobets, Вы писали:
Ф>>Практика показала, что "готовые решения" тоже желательно тестировать.
YK>Да-да, принцип "хочешь сделать хорошо — сделай сам" действует практически безотказно
Но сколько времени это займёт? Как альтернатива: "...переделай сам" или "... доделай сам"
Здравствуйте, Философ, Вы писали:
Ф>>>Я ради эксперимента писал собственные контейнерные типы (напр. LinkedList), как для .Net так и Delphi. Ф>>>Почти каждый раз получалось медленнее аналогов. Иногда чуть-чуть, а иногда очень заметно. Ф>>>Искал причины, отлаживал, дорабатывал...
CEM>>И? Получилось же?
Ф>Я не буду отвечать на этот вопрос. Я это делал не для того, чтобы получилось.
Я так так понял, всё же ответил А зачем делать, если нету цели сделать? Научиться? Но научиться — это как раз добиться цели, и чтоб всё заработало. Если не сделал — не научился делать.
CEM>>Меня настораживают два слова тут: Delphi & .Net Всё что на них пишется, работать быстрее не может по умолчанию (извините, не удержался).
Ф>"быстрее, чем что?" — это должен быть основной вопрос. я говорил об аналогах для тех же Delphi и .Net.
Провокация! Быстрее, чем всё остальное.
CEM>>Потому что всё что я писал, ради интереса или нет, работало вроде быстрее. Или удобнее. Вобщем, не зря начинал. Ф>Я тоже не зря начинал. Уж поверьте!
Верю!
Ф>Кстати, ТС таки бы посоветовал всё же писать свою СУБД
Возможно. Но хоть какой-нибудь результат труда должен быть, не только какой-то набитый код, который не имеет никакой ценности. Труд ценен результатом.
Опыт — тоже продукт получения реального результата.
Ф>>>Часто, при аналогичной алгоритмов проигрывал в скорости чуть-чуть (секунда — полторы на миллион операций). Ф>>>Пробовал писать свой мэнеджер памяти (начинал писать)... Ф>>>Пришёл к выводу, что это пустая трата времени (в большинстве случаев). CEM>>Я бы ещё сюда добавил, что готовые решения, как правило, отлажены хорошо. А свой код ещё погонять надо...
Ф>Практика показала, что "готовые решения" тоже желательно тестировать.
Без этого никак. Даже винду проверять надо
Здравствуйте, YuriKobets, Вы писали:
CEM>>Но сколько времени это займёт?
YK>Это уже второй вопрос
Нет, это как раз первый вопрос. Потому что время — очень важный ресурс.
CEM>>Как альтернатива: "...переделай сам" или "... доделай сам"
YK>Это не альтернатива. Это следствие игнорирования тезиса "хочешь сделать хорошо — сделай сам"
Ну не правда. Глупо же делать _всё_ с нуля? Иначе "хочешь сделать хорошо — садись пиши user32.dll, kernel32.dll, ntdll.dll, gdi32.dll, итд итп.dll..."
Должна быть какая-то разумная грань между "возьми готовое" и "напиши своё".