Comments 13
Очередная статья критикующая пословицу о вреде ранней оптимизации, но вновь меня не убедившая. Где сейчас GoChat, который упал во время презентации инвесторам? «Прозябает» с жалким миллионом пользователей. Где сейчас twitter, прославившийся своим Fail Whale? Пережил кризис и успешно задавил всякие juick'и.
Уж лучше моя программа не переживёт взрывного роста, чем вообще не увидит взрывного роста, потому что кто-то опередит меня.
Уж лучше моя программа не переживёт взрывного роста, чем вообще не увидит взрывного роста, потому что кто-то опередит меня.
А я наоборот увидел в статье золотую середину.
Я спать бы не смог, если моя разработка обрела бы популярность, а затем свалилась бы под нагрузкой только потому, что она плохо спроектирована. Я встроил в приложение минимально жизнеспособные принципы масштабирования.
Я как раз 10 минут назад обдумывал тему «ранней оптимизации». Да, надо делать просто — оставлять задел под будущее возможное масштабирование. И всё. Казалось бы очевидно.
На мой взгляд в статье все-таки говорится о правильном выборе инструментов для создания приложения. Ведь GoSnaps взлетел потому, что его автор многое продумал заранее и выбрал подходящую архтиектуру и инструменты.
Да нету здесь в статье никакой оптимизации. Не преждевременной, не какой-либо другой. Вот если бы он написал код поиска картинки на C или ASM, добавил бы "full kernel bypass", чтоб не нарываться на тормоза ядра операционки, ну и CUDA/OPENCL, для быстрого ресайза картинок. Вот это была бы оптимизация.
А догадаться не хранить картинки в базе данных это не оптимизация, это просто нормальный инженерный подход, который да, почти не распространен из-за крайне низкого уровня "программистов".
Затронуть тему масштабирования, и при этом не указать на какой паттерн опиралось приложение при его разработке? MVVM, MVC, MVP? MVP в контексте это Minimum viable product, что является философией, но никак не паттерном при разработке приложения
С php понятно, но почему python+django медленный? Чем nodejs так сильно быстрее, если не брать в рассмотрение трансляцию js в машинный код?
Предположу, что асинхронностью.
Медленный быстрый не имеет значения. Кому как удобнее на каком языке программировать. Но и стоит учитывать что разные языки имеют разные преимущества и недостатки. Как и основное свое предназначение.
Субъективно — все неспешные скриптовые языки выживают на серверах только потому, что они добавляют не так уж много логики к СУБД.
Вытащили данные, обработали, сгенерировали html, присыпали статикой и отдали клиенту. Либо вообще отдали статикой SPA, сервера реализовали API — по сути, представление над БД и контроль доступа, а тяжёлый код достался браузеру на клиенте (у него своё железо, голова разработчиков о нём не так болит).
А суть же происходящего остаётся на уровне БД — там где оптимизированный низкоуровневый код, написанный и оттестированный кем-то ещё. Там доступ к данным и их тяжёлая обработка, там же индексы, там же поддержка транзакций.
Вытащили данные, обработали, сгенерировали html, присыпали статикой и отдали клиенту. Либо вообще отдали статикой SPA, сервера реализовали API — по сути, представление над БД и контроль доступа, а тяжёлый код достался браузеру на клиенте (у него своё железо, голова разработчиков о нём не так болит).
А суть же происходящего остаётся на уровне БД — там где оптимизированный низкоуровневый код, написанный и оттестированный кем-то ещё. Там доступ к данным и их тяжёлая обработка, там же индексы, там же поддержка транзакций.
В этом плане и js(nodejs) и python(django) мало отличаются, оба скриптовые, только в nodejs асинхронность и колбеки + трансляция в машинный код. Но я спрашивал про сравнение именно этих технологий между собой, почему нода прям так сильно быстрее, что автору пришлось бы «целыми днями заниматься ускорением медленных компонентов, либо добавлять сервера».
Моей основной мыслью было, что на самом деле, автор в плане выбора платформы рассуждает о пустом. Главное — выбрать адекватную СУБД и написать к ней адекватные запросы.
Что же насчёт сравнения технологий…
Насколько я могу понять, автор катит бочку в том числе на раздутость фреймворков.
Тормозной код ведь можно написать на любом языке, под любую платформу.
За быстроту самих же технологии не возьмусь с уверенностью говорить, ибо не вылазил с бенчмарками за пределы Java, а точнее — JVM, под которую, в основном, пишу.
По идее — код на питоне и php будет отличаться только тем, что будет исполняться из закешированного байткода/опкода, а не из нативного кода, и этот байткод/опкод придётся в процессе выполнения интерпретировать, что замедляет выполнение.
Если я корректно понимаю, V8 же будет аналогично кешировать результат компиляции, но в нативном коде, что позволит выполнять его быстрее. Это в какой-то степени похоже на JVM, где предварительно скомпилированный байткод будет интерпретироваться, пока не наберёт статистику выполнения (порядка нескольких тысяч медленных прогонов), и JVM не скомпилирует его части в бинарный код, после чего он станет быстрым.
Что же насчёт сравнения технологий…
с использованием более медленной среды исполнения кода, или на основе неповоротливого фреймворка
Насколько я могу понять, автор катит бочку в том числе на раздутость фреймворков.
Тормозной код ведь можно написать на любом языке, под любую платформу.
За быстроту самих же технологии не возьмусь с уверенностью говорить, ибо не вылазил с бенчмарками за пределы Java, а точнее — JVM, под которую, в основном, пишу.
По идее — код на питоне и php будет отличаться только тем, что будет исполняться из закешированного байткода/опкода, а не из нативного кода, и этот байткод/опкод придётся в процессе выполнения интерпретировать, что замедляет выполнение.
Если я корректно понимаю, V8 же будет аналогично кешировать результат компиляции, но в нативном коде, что позволит выполнять его быстрее. Это в какой-то степени похоже на JVM, где предварительно скомпилированный байткод будет интерпретироваться, пока не наберёт статистику выполнения (порядка нескольких тысяч медленных прогонов), и JVM не скомпилирует его части в бинарный код, после чего он станет быстрым.
Sign up to leave a comment.
История моего стартапа: 500000 пользователей за 5 дней на стодолларовом сервере