Вопрос собственно в следующем - какие средства или какие методы вы используете для профилирования своего кода?
Профилирование — сбор характеристик работы программы. Инструмент, используемый для анализа работы называют профайлером. Таким образом профилирование помогает найти критические (по времени выполнения) участки программы, ускорить работу приложения за счет оптимизации затратных участков кода! Одним словом профилирование помогает увидеть вам на какие участки кода тратится больше всего времени выполнения!
Ну вопервых скорость работы CPU уже давно не удваиваеться так быстро, нету удвоения производительности. Если они имееют ввиду переход с 2х ядерных процессоров на 4-х ядерные - они правы, но частично. Такой переход приносит ещё и свои проблемы. Мы, к примеру (и я об этом писал уже здесь на форуме) столкнулись с проблемой, при которой MySQL не может просто работать на 4-х ядерном процессоре. CPU настолько быстр, что родительский процесс просто не успевает менеджить потоки MySQL'a - в итоге база уходит в взаимную блокировку потоков буквально в течении 5-6 минут под нагрузкой. Могут возникнуть и другие проблемы. Если PHP скриптам всёравно сколько CPU у сервера и как правило, чем больше, тем лучше, то базе это не поможет, т.к. у неё другие ограничения, совсем не по CPU и RAM. Вообщем я не согласен с высказанным там мнением. Код надо уже изначально писать так, что бы его не пришлось переписывать. Уж такие простые вещи как циклы и.т.д. можно и нужно сразу писать нормально. Как правило сами циклы редко становятья проблемой, скорее то, как написан код в нутри них или окружающий код. Очень часто можно увидеть изобретение велосипеда или реализацию каких-то вещей (особенно работа с массивами) в ручную, хотя такие функции есть в PHP встроенные. Перепишите такие места и вы можете получить колосальный прирост скорости. Есть и другие способы оптимизации, особенно WEB проэктов. И реализация некоторых требует буквально пару часов работы мозгами и 10 минут написания кода.
Это другой вопрос. В статье четко все описано — о том что оптимизация не имеет былой ценности, на первое место выходит количество возможностей.
Тоже верно, но баланс между оптимизацией и фитчами тоже необходимо соблюдать, потому что если ты делаешь что-то большое, ты 100% упрёшься в лимиты железок. А делать распределённые кластерные системы куда сложнее простой оатимизации.
Надо просто трезво проектировать и реализовывать. Сказано в ТЗ, что планируемая нагрузка такая-то, функциональность такая-то, производительность такая-то, расширяемость такая-то, всё, утвердили, разработали, требованиям удовлетворяет, претензий быть не может. А если потом потребуется функционал и нагрузку удвоить, то это уже возможно совсем другой проект, основанный на других принципах. По-этому всякое профилирование - это фигня. В процессе разработки надо думать, а не искать потом узкие места когда всё уже висит...
Hight К сожалению на практике в 90% случаев выползают такие вещи, о которых зарание подумать не получаеться. + вы не можете видить всей картины, если у вас страницу генерирует 5-6 модулей. Тут поможет только профилирование, что бы увидить узкие места. А они не всегда очевидны.
Psih На практике по-настоящему хороший спец должен всё предусмотреть заранее и внести в ТЗ (проектная документация), чтобы потом не оправдываться перед заказчиком за косяки. По-этому на составление ТЗ уходит много времени и составляет его не один человек, а комманда разработчиков, но зато есть гарантия, что реализация пройдёт гладко и быстро. В результате к моменту утверждения ТЗ весь код в голове уже есть, его остаётся только перенести в компьютер. А профилирование настоящему спецу нафиг не нужно, нафиг не нужны какие-либо инструменты для этого, он и так знает где может быть падение производительности. И все эти нюансы должны быть продуманы ещё при составлении ТЗ. ИМХО конечно. (просто не люблю спорить по ерунде)
Очень сомнительное высказывание! уж больно все просто у вас и уж больно много должен уметь настоящий спец, прямо-таки не человек а машина рассчитывающая в голове все вариации логики кода, производительность участков и т.д. Верится с трудом в таких профессионалов!!
enshtein не сказал бы. Естесственно не все прямо до единной буквы, но суть и основные моменты как минимум в голове уже прокручиваются, а значит без труда будут перенесены в компьютер
Загляните в хороший автосервис, позовите спеца, заведите свою машину и спросите его: что с моей машиной не так. Человек походит вокруг, послушает, посмотрит там сям и через 5 минут назовёт вам возможные косяки вашего автомобиля. В программирование тоже самое. Если вы не можете заранее увидеть возможные косяки при разработке, вы не настоящий спец, а простой кодер. По-этому процесс составления ТЗ считаю одним из наиболее важных моментов реализации проекта. Кто-то не согласен? Кто-то работает без ТЗ?
ИМХО конечно! НОООО... мнение о том, что критические участки кода можно определить полагаясь чисто на свою интуицию, не что иное как самонадеянность. Это все равно - что автомеханик будет утверждать, что без тестирования знает причину неэффективности работы двигателя, или врач который будет твердить о том, что знает причину всех заболеваний пациента без анализов! В любом случае хотелось бы немного разграничить то о чем мы с вами говорим: давай процесс Профилирования кода разделим на две части: 1) Методы диагностики - это как раз то про что вы говорили (знание как работают операторы с точки зрения производительности, программерская интуиция) 2) Инструменты диагностики - это как раз профайлеры
нуу... нескажите... нескажите... сервисмэны бывают разные, да и потом автомобиль - это система взаимосвязанных элементов, а потому диагностика - это лучший помошник в устранение проблем! Да я не спорю бывает интуиция и у врачей, и у техспециалистов и у программистов - однако интуиция может и подвести - неправда ли?