Как Производительность Accurev?
Если это - что-то, что Вы заканчиваете тем, что часто делали, и с различными операциями, необходимо, вероятно, создать класс, чтобы обработать случаи как это или лучше пользоваться некоторой библиотекой как Numpy.
Иначе, ищите понимания списка используемый с zip встроенная функция:
[a_i - b_i for a_i, b_i in zip(a, b)]
1 ответ
У меня нет цифр, но я могу сказать вам, где мы заметили проблемы с производительностью.
Наши сборки обычно используют 30-40K файлов из системы контроля версий. В моем рабочем пространстве в настоящее время находится более 66К файлов, включая промежуточные и выходные файлы сборки, размером более 15 ГБ. Чтобы AccuRev работала быстро, мы активно используем элементы игнорирования , поэтому AccuRev игнорирует любые промежуточные файлы, такие как * .obj. Кроме того, мы используем оптимизацию меток времени . В общем, обновление выполняется быстро, но размер проекта обычно составляет 5-10 человек, поэтому обычно остается только пара десятков файлов, если вы обновляете ежедневно. Даже если кто-то внес изменения, которые коснулись большого количества файлов, скорость не проблема. С другой стороны, заполнение всех файлов размером более 30 КБ выполняется медленно. Я не У меня нет времени, так как я редко делаю это, и в редких случаях я управляю населением, когда собираюсь на обед или встречу. Я думаю, это может занять до 10 минут. Обычно исходные файлы загружаются очень быстро, но у нас есть несколько больших двоичных файлов, 10-20 МБ, каждый из которых занимает пару секунд.
Если правила исключения и элементы игнорирования настроены неправильно, AccuRev может занять пару секунд. минут на запуск обновления для рабочих областей такого размера. Когда я слышу, как другие разработчики жалуются на скорость, я знаю, что что-то неправильно настроено, и мы исправляем это.
Примерно год назад один из проектов обновил boost с 25K + файлами, а также добавил FireFox в репозиторий (забудьте размер, но заставил boost выглядеть маленьким.) Они также добавили ICU, написали много программного обеспечения и изменили бесчисленное количество файлов. Насколько я помню, в потоке находилось около 250К + файлов. К сожалению, я решил, что весь их хороший код должен быть переведен в корневой каталог, чтобы все проекты могли делиться им. Это оказалось немного выше того, с чем AccuRev могла хорошо справиться. Процесс продвижения всех изменений занял много часов. Насколько я помню, после того, как FireFox был продвинут, все остальное прошло гладко - возможно, проблема была в одной транзакции с более чем 100 КБ файлов?
Я недавно обновил boost, и поэтому мне пришлось хранить и продвигать более 25 КБ файлов. Это заняло минуту или две, но вполне разумно, учитывая количество файлов и размер двоичных файлов.
Что касается количества потоков, у нас более 800 потоков и рабочих областей. Производительность здесь не проблема. В общем, мне сложно ориентироваться в большом количестве потоков, поэтому я запускаю отфильтрованное представление только о моих рабочих областях и только о потоках, которые меня интересуют. Однако, когда мне нужно посмотреть на неотфильтрованный список, чтобы найти что-то, производительность в порядке.
В заключение отметим, что поддержка AccuRev потрясающая - мы называем их голосом в небе. Время от времени мы стреляем себе в ногу с помощью AccuRev и не понимаем, как что-то исправить. Почти всегда мы делали что-то глупое, а затем пытались исправить это чем-нибудь еще более глупым. В конце концов, мы отправляем запрос на поддержку, и следующее, что мы знаем, они проводят нас через шаги к праведности либо по телефону, либо на встрече goto. Я даже связывался с ними по пустякам, в которых у меня просто нет времени разбираться, поскольку я '