Однако тут есть нюанс, который мало кто учитывает. Есть такая штука как время старта. Т.е. когда вы запускаете сам тест и прежде чем дошло до строчки запуска таймера — прошло дофига времени. И иногда именно это решает все.
S>Однако тут есть нюанс, который мало кто учитывает. Есть такая штука как время старта. Т.е. когда вы запускаете сам тест и прежде чем дошло до строчки запуска таймера — прошло дофига времени. И иногда именно это решает все.
Покажи хотя бы два примера, где это время оказалось сильно противоречащим скорости самого приложения.
Здравствуйте, netch80, Вы писали:
N>Покажи хотя бы два примера, где это время оказалось сильно противоречащим скорости самого приложения.
JIT-платформы при запуске производят овердофига процессов — а потом работают вроде как быстро. Та же Java или .Net — стартуют дофига медленно, хотя сама работает норм.
Я все больше обращаю внимание на время старта, ведь иначе приходится держать приложение горячим — а это доп. расходы.
Здравствуйте, Shmj, Вы писали:
дофига времени. И иногда именно это решает все.
раздражает уж точно. как и размер ХВ в сто с лишним МБ.
Что довольно заметно при передаче по 3G
S>Однако тут есть нюанс, который мало кто учитывает. Есть такая штука как время старта. Т.е. когда вы запускаете сам тест и прежде чем дошло до строчки запуска таймера — прошло дофига времени. И иногда именно это решает все.
1. Это не нюанс, а совсем перпендикулярный параметр. Время старта часто не имеет значения.
2. Надо измерять уже не время работы фрагмента кода, а время старта некоего приложения, как бы одного и того же, но на разных языках. Кроме языков, добавится зависимость от платформы; каждый тест надо запускать на чистой системе и далее в такоим духе.
В итоге будет дешевле найти какой-нибудь другой повод для срача.
Здравствуйте, netch80, Вы писали:
N>Покажи хотя бы два примера, где это время оказалось сильно противоречащим скорости самого приложения.
У меня в одной из виртуалок стоит VS 2019. Ей нужно 25 с, чтобы показать окно, еще 40, чтобы перестал шевелиться значок возле "Ready" в Status Bar, и еще 15 — чтобы начать реагировать на команды. Система в этой виртуалке загружается примерно на десять секунд быстрее.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У меня в одной из виртуалок стоит VS 2019. Ей нужно 25 с, чтобы показать окно, еще 40, чтобы перестал шевелиться значок возле "Ready" в Status Bar, и еще 15 — чтобы начать реагировать на команды. Система в этой виртуалке загружается примерно на десять секунд быстрее.
У меня комп старенький, лет пять назад собирал, и то не самый новый, правда, SSD на гиг с основным софтом, в тч вижуалка. Студия 2019 стартует секунд за 5, ещё 5 что-то раздупляет по проекту, и можно работать
Здравствуйте, Marty, Вы писали:
M>У меня комп старенький, лет пять назад собирал, и то не самый новый
У меня ноутбук 2015-го года. Но VS 2008 на нем работает прекрасно. На прежнем ноутбуке 2012-го года работала так же.
M>правда, SSD на гиг с основным софтом, в тч вижуалка.
Эта виртуалка у меня на HDD, ибо пользуюсь ею редко. На SSD студия явно будет запускаться быстрее. Но фишка-то в том, что одно приложение, далеко не самое толстое, запускается дольше, чем загружается вся винда (семерка). А винда, как известно, тоже очень далека от оптимальности, и тоже делает очень много совершенно ненужных действий.
То есть, использование SSD всего лишь позволяет частично скрыть то огромное количество косяков, которое наплодили в таких приложениях за время их "совершенствования".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Эта виртуалка у меня на HDD, ибо пользуюсь ею редко. На SSD студия явно будет запускаться быстрее. Но фишка-то в том, что одно приложение, далеко не самое толстое,
Неправда. Приложение весьма толстое. И оно грузит не бинари, как система, а подозреваю, много чего в самых разных форматах, которые в тч надо на ходу парсить. Ты наверно, не видел, как Clion или Eclipse загружаются и работают
ЕМ>запускается дольше, чем загружается вся винда (семерка). А винда, как известно, тоже очень далека от оптимальности, и тоже делает очень много совершенно ненужных действий.
Вторая демагогия. Как известно И современная винда весьма шустра
ЕМ>То есть, использование SSD всего лишь позволяет частично скрыть то огромное количество косяков, которое наплодили в таких приложениях за время их "совершенствования".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>VS 2008 на нем работает прекрасно.
Вообще лучшая вижуалка. Прикручиваешь к ней VAX и сторонний компилер и она заруливает всё остальное. До сих пор ей пользуюсь и горя не знаю.
Здравствуйте, Marty, Вы писали:
M>Приложение весьма толстое.
А винда еще толще. Но ей таки хватает ума не грузить сразу все, что может понадобиться любому из ее пользователей в любое время, а ограничиться более-менее необходимым. И по требованию она подгружает дополнительное достаточно быстро.
M>И оно грузит не бинари, как система, а подозреваю, много чего в самых разных форматах, которые в тч надо на ходу парсить.
Зачем каждый раз "парсить на ходу" то, что не меняется со временем? Даже то, что может меняться время от времени, нужно парсить после изменения, а не каждый раз. Она ж создает для каждого проекта базу невменяемого размера (в 50 раз больше объема текста), вот и для своего контента тоже создавала бы.
M>Ты наверно, не видел, как Clion или Eclipse загружаются и работают
Если так же, то и слава богу.
M>Вторая демагогия. Как известно
Тем, кто более-менее знаком с потрохами винды, это вполне себе известно. А те, кто ее использует "как есть", полагают, что иначе просто невозможно.
M>И современная винда весьма шустра
Вы путаете современную винду с современным же железом. Еще ни одна винда не работала не только шустрее, но и хотя бы так же, как предыдущие, на железе той же производительности. Вы просто ставите современную винду, студию и прочее на современные же процессор и SSD, и не видите, как они бессмысленно перемешивают гигабайты триллионами операций в секунду.
M>Или не косяков, а фич, которым дофига чего надо
Ничего не имею против фич, которые никак себя не проявляют, пока не потребуются. В адекватные времена все эти фичи вообще лежали на установочном диске или сервере до тех пор, пока из оттуда не затребуют явно. В те времена, пока не было пакетов и сложных зависимостей, MS справлялась с разделением функций гораздо лучше. Теперь, когда все это есть, единственным применением этого механизма стало обновление.
Здравствуйте, CreatorCray, Вы писали:
CC>Прикручиваешь к ней VAX и сторонний компилер и она заруливает всё остальное. До сих пор ей пользуюсь и горя не знаю.
У Вас компиляторы прикручены через External Tools, или через родной механизм? Я через External Tools гоняю компилятор под ARM64, но неудобно.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У Вас компиляторы прикручены через External Tools, или через родной механизм? Я через External Tools гоняю компилятор под ARM64, но неудобно.
Для своих проектов у меня ICC прикручен, у него родная интеграция
Но я его давно не обновлял ибо как то надобности не было, да и в новых они поддержку 2008й грохнули.
Когда на VMW работал то у меня и вовсе был прикручен внешний компилятор который через ssh запускался на buildserver а output шёл в родное Output вижуалское окошко.
Тогда мне было лень возиться и я просто через makefile прикрутил.
Здравствуйте, CreatorCray, Вы писали:
CC>Для своих проектов у меня ICC прикручен, у него родная интеграция
А у VAX нормально с подсветкой синтаксиса и навигацией в коде C++11? Я когда-то давно пробовал Visual Assist, но чем-то он мне не понравился — то ли тормозил сильнее родного IntelliSense, то ли глючил. С тех пор не возвращался к нему.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А у VAX нормально с подсветкой синтаксиса и навигацией в коде C++11?
Пока ничего эдакого не видел. Ему иногда башню подсрывает, особенно когда много между разными версиями кода переключаешься, но команда Reparse file всё чинит.
ЕМ> Я когда-то давно пробовал Visual Assist, но чем-то он мне не понравился — то ли тормозил сильнее родного IntelliSense, то ли глючил. С тех пор не возвращался к нему.
Поставь триал и посмотри на своём коде. Думаю так будет продуктивнее чем гадать.