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