Если б знать где упасть… Эта методика нужна до того, как поставить точку останова. То есть вопрос не в том, исполняется ли одна конкретная ветка. Проблема где-то в коде, но точное место неизвестно. По результатам замера можно одновременно увидеть как исполняются все ветки и сразу увидеть проблемное место. И когда уже проблема локализована, можно поставить точку останова на условие (если оно сложное) и определить, почему условие или цикл работает неправильно. Особенно удобно просматривать замеры на больших участках кода. Не знаю, понятно ли будет на небольшом примере.
Вот функция, которая должна найти сумму все чисел от 0 до 99, за исключением числа, переданного как параметр.
int SumExcept(int x)
{
1: int s = 0;
100: for (int i = 0; i < 100; i++)
100: {
100: if (x = i)
100: continue;
s += i;
}
1: return s;
}
В функции ошибка — она всегда возвращает 0. Первое, на что можно подумать – цикл не выполнился ни разу. Но прежде, чем ставить точку останова на цикл, давайте посмотрим на замер.
Цикл выполнился 100 раз, то есть проблема не в цикле. Условие так же проверилось 100 раз – это правильно. Но почему-то условие всегда истинно – оператор continue выполнился 100 раз. Итак проблема локализована — она в условии! Ой, как стыдно, вместо равенства оператор присваивания!
Пробегая отладчиком по коду, мы бы увидели то же самое, но в замере мы сразу видим работу всех циклов и условий в один момент времени. Да и точку останова уже можно не ставить — и так все понятно.
В циклах небольшой набор инструкций может выполняться довольно долго. Ну да ладно, с оптимизацией. Есть еще одно применение — отладка.
По результатам замера производительности удобно анализировать выполнение кода. Можно сразу увидеть, какие ветки условий сработали, какие блоки кода не выполнялись вообще, и сколько раз прокрутились циклы.
После такого взгляда на код обычная отладка «скаканием» по каждой строке покажется вам унылым занятием.
Интересно, что показало бы сравнение на одинаковом железе:
1. Выполнение циклов на клиенте и на сервере.
2. 32-х разрядный и 64-разрядный сервер.
3. Сервер на винде и на линуксе.
А, ясно. После голосования уже не видно, флажки это были или кружки. А ввели в заблуждение формулировки вопросов в единственном числе: «под какой ОС» и «язык программирования». Да и как можно выбрать более одного варианта на вопрос о наибольшей частоте?
В случае отдельных баз могли бы решиться некоторые проблемы, например эти:
• если кто-то из пользователей запорол данные в одной организации, приходится откатывать назад всю разделённую базу — нельзя просто взять и откатить одну область данных
• если нужно передать базу клиенту (или слить налоговой:), приходится делать обратную процедуру: выгружать организацию из разделённой базы при помощи универсального обмена, затем загружать в пустую обычную базу и из неё сохранять в.dt-файл
А вот если бы 1С была устроена немного иначе. Скажем, каждая база не содержала бы метаданные, а только хранила бы данные пользователей. А конфигурация располагалась бы на сервере где-то в другом месте (в файлах md как в 7.7 или на SQL сервере в отдельной базе метаданных).
Тогда можно будет создавать несколько баз одной конфигурации, а при обновлении конфигурации чтобы проходило автоматическое обновление всех баз этой конфигурации.
И еще так же отдельно хранились бы пользователи.
Формально, можно экономить на лицензиях, так как каждый бухгалтер будет запускать несколько копий одной базы, а не десяток разных.
Не очень понятно как происходит экономия лицензий. Если у вас лицензии раздает сервер, один сеанс будет использовать одну лицензию. И неважно отдельные это базы или одна разделенная.
Экономить на лицензиях можно менеджером лицензий. Если им раздавать лицензии, одна лицензия действует на один клиентский компьютер независимо от количества открытых баз или количества открытых сеансов.
А эти исследователи не замечали, что опытный водитель мониторит ситуацию на дороге «в фоновом режиме»? И когда на дороге нет нестандартной ситуации, вниманию опытного водителя нечем заняться. Поэтому водители и начинают занимать освободившееся сознание бутербродами, сигаретами, разговором с пассажирами, телефоном. Причем инициатором таких отвлечений часто является сам водитель. Но как только дорожная ситуация требует внимания, водитель прерывает разговор и перестает жевать. Хочу уточнить, что так ведут себя только опытные водители.
Попробую встать на защиту и обосновать гордость программиста, которого знает Эли Бендерски.
Код, который мы читаем, можно классифицировать:
1) Чужой код.
2) Код, который я написал сейчас.
3) Код, который я написал давно.
Чужой код оценить легко. Либо все понятно и красиво, либо я написал бы лучше (чаще всего второе). Мы легко видим недостатки чужого кода: архитектурные оплошности, неудачные идентификаторы, непонятные комментарии, и т.д.
В нашем коде между 2 и 3 пунктом лежит временной интервал. Насколько он длинен? Должно пройти время, пока мы забудем то, что писали, и будем относиться к коду как к чужому. Выполнять рефакторинг можно будет тогда, и только тогда, когда произойдет отстранение от своего кода. До этого момента мы к своему коду относимся предвзято. Именно этим и гордится этот программист — тем, что он может беспристрастно анализировать свой код уже через неделю.
Вы видите оповещение о том, что один из ваших потенциальных клиентов просматривает прайс-лист на сайте. Теперь Вы точно знаете, что сейчас удачное время для звонка и завершения сделки
Только если клиент не сидит в туалете и просматривает ваш прайс чтобы заморочиться.
Вот функция, которая должна найти сумму все чисел от 0 до 99, за исключением числа, переданного как параметр.
В функции ошибка — она всегда возвращает 0. Первое, на что можно подумать – цикл не выполнился ни разу. Но прежде, чем ставить точку останова на цикл, давайте посмотрим на замер.
Цикл выполнился 100 раз, то есть проблема не в цикле. Условие так же проверилось 100 раз – это правильно. Но почему-то условие всегда истинно – оператор continue выполнился 100 раз. Итак проблема локализована — она в условии! Ой, как стыдно, вместо равенства оператор присваивания!
Пробегая отладчиком по коду, мы бы увидели то же самое, но в замере мы сразу видим работу всех циклов и условий в один момент времени. Да и точку останова уже можно не ставить — и так все понятно.
По результатам замера производительности удобно анализировать выполнение кода. Можно сразу увидеть, какие ветки условий сработали, какие блоки кода не выполнялись вообще, и сколько раз прокрутились циклы.
После такого взгляда на код обычная отладка «скаканием» по каждой строке покажется вам унылым занятием.
1. Выполнение циклов на клиенте и на сервере.
2. 32-х разрядный и 64-разрядный сервер.
3. Сервер на винде и на линуксе.
Может быть это опечатка?
Может быть лучше перевести «чтобы реализовать новые функции» или «новую фичу».
И, кстати, о сути. Почему размещение депозитов сразу не сделали?
Тогда можно будет создавать несколько баз одной конфигурации, а при обновлении конфигурации чтобы проходило автоматическое обновление всех баз этой конфигурации.
И еще так же отдельно хранились бы пользователи.
Не очень понятно как происходит экономия лицензий. Если у вас лицензии раздает сервер, один сеанс будет использовать одну лицензию. И неважно отдельные это базы или одна разделенная.
Экономить на лицензиях можно менеджером лицензий. Если им раздавать лицензии, одна лицензия действует на один клиентский компьютер независимо от количества открытых баз или количества открытых сеансов.
Код, который мы читаем, можно классифицировать:
1) Чужой код.
2) Код, который я написал сейчас.
3) Код, который я написал давно.
Чужой код оценить легко. Либо все понятно и красиво, либо я написал бы лучше (чаще всего второе). Мы легко видим недостатки чужого кода: архитектурные оплошности, неудачные идентификаторы, непонятные комментарии, и т.д.
В нашем коде между 2 и 3 пунктом лежит временной интервал. Насколько он длинен? Должно пройти время, пока мы забудем то, что писали, и будем относиться к коду как к чужому. Выполнять рефакторинг можно будет тогда, и только тогда, когда произойдет отстранение от своего кода. До этого момента мы к своему коду относимся предвзято. Именно этим и гордится этот программист — тем, что он может беспристрастно анализировать свой код уже через неделю.
Только если клиент не сидит в туалете и просматривает ваш прайс чтобы заморочиться.