Закон Wirth все еще сохраняется?
Ваша функция далеко не пригодна для использования :) Попробуйте вместо этого просто уменьшить:
weatherArray.reduce((accumulator, current) => {
// check if given city is already in reducing array result
let cityExists = accumulator.findIndex(k => k.Location === current.Location)
if(cityExists > -1) {
// there is a city in resulting array, check values and perhaps update
if(accumulator[cityExists].Rainfall < current.Rainfall) {
accumulator[cityExists].Rainfall = current.Rainfall
accumulator[cityExists].Date = current.Date
}
} else {
// no such city, just add it
accumulator.push(current)
}
return accumulator
}, []) // start with an empty array
13 ответов
Да я думаю, что это верно.
Как я измеряю скорость программного обеспечения? Хорошо время для решения задач является соответствующим индикатором. Для меня как пользователь программного обеспечения я не забочусь, существует ли 2 или 16 ядер в моей машине. Я хочу, чтобы моя ОС загрузилась быстро, мои программы для запуска быстро, и я абсолютно не хочу ожидать простых вещей как вводные файлы, которые будут сделаны. Программное обеспечение должно просто чувствовать себя быстрым. Так.. при начальной загрузке Windows Vista нет никакого быстрого программного обеспечения, которое я смотрю.
Программное обеспечение / Платформы часто улучшает их производительность. Это является большим, но это главным образом незначительные изменения. Исключение доказывает правило :)
По-моему, это - все о чувстве. И такое чувство, что компьютеры были несколько более быстрых годы назад. Конечно, я не мог выполнить текущие игры и программное обеспечение на тех старых машинах. Но они были просто быстрее :)
It не, что программное обеспечение становится медленнее, случается так, что его сложность увеличивается.
Мы теперь полагаемся на многие уровни абстракции.
Когда был прошлый раз людьми на ТАК кодированном в ассемблере?
Больше всего никогда не имейте, и никогда не будет.
Это неправильно. Корректный
Программное обеспечение становится медленнее на том же уровне, как аппаратные средства становятся быстрее.
Причина состоит в том, что это главным образом определяется человеческим терпением, которое остается таким же. Это также забыло упоминать, что программное обеспечение сегодня делает больше чем 30 лет назад, даже если мы игнорируем усладу для глаз.
Заключение в кавычки от исследования UX:
Технический прогресс 21 года поместил современные ПК в совершенно другую лигу варьировавшихся мощностей. Но “Пользовательский Опыт” не изменился очень за два десятилетия. Из-за чрезмерно увеличенного в размерах кода, который должен включить сотни функций, которые даже не знают средние пользователи, существуют, уже не говоря о когда-либо используют, компании-разработчики программного обеспечения пригнули наши ПК для эффективной нейтрализации их обширных преимуществ скорости.
Подробное сравнение UX на старинном Mac и современном Двухъядерном: http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins
На основе моего собственного опыта я должен не согласиться с законом Wirth.
Когда я сначала приблизился к компьютеру (в 80'), время для отображения маленького неподвижного изображения было заметно. Сегодня мой компьютер может декодировать и отобразить фильмы AVCHD на 1 080 пунктов в в реальном времени.
Другой индикатор является кадрами в секунду видеоигр. Недавно это раньше было приблизительно 15 футов в секунду. Сегодня 30 кадров в секунду к 60 кадр/с весьма распространены.
В целом закон сохраняется. Как Вы заявили, существуют исключения, "которые доказывают правило". Мой брат недавно установил Win3.1 на своих 2 ГГц + ПК, и он загружается моментально глаза.
Я предполагаю, что существует много причин, почему закон содержит:
- Многие программисты, вводящие профессию теперь, никогда не должны были рассматривать ограниченную скорость / снабженные системы, таким образом, они никогда действительно думают о производительности своего кода.
- Обычно существует более высокая важность при получении кода, написанного в течение крайних сроков, и производительность, настраивающаяся обычно, является последней после устранения ошибки / новые возможности.
Я нахожу отсутствие FF непосредственного диалогового окна всплеска раздражающим, поскольку оно требует времени, чтобы главное окно появилось после запущения приложения, и я никогда не уверен, 'работал' ли щелчок. OO также страдает от этого.
Существует несколько статей о сети об изменении восприятия скорости программного обеспечения, не изменяя действительную скорость.
Править:
В дополнение к вышеупомянутым точкам примером низкой важности, данной эффективности, является этот сайт, или скорее большинство других сайтов Вопросов и ответов. Этот сайт всегда разрабатывался, чтобы быть быстрым и быстро реагирующим, и он показывает. Сравните это с другими сайтами там - я нашел, что phpBB базировался, сайты являются гибкими, но медленными. Google является другим примером помещения скорости высоко в важности (это даже говорит Вам, сколько времени поиск взял) - соответствуют другим поисковым системам, которые были вокруг, когда Google запустился (теперь, они все быстры благодаря Google).
Прилагает много усилий, навыка и опыта сделать быстрый код, который является чем-то, что я нашел, что многим программистам недостает.
Моя машина становится медленнее и более неуклюжей каждый день. Я приписываю большую часть замедления под управлением антивирусу. Когда я хочу убыстриться, я нахожу, что отключение антивируса творит чудеса, хотя я являюсь опасающимся как то, чтобы быть в захудалом борделе.
Я думаю, что закон Wirth был в основном вызван Законом Гордона Мура - если бы Ваш код отстал, то Вы просто игнорировали бы, с тех пор достаточно скоро, он работал бы достаточно быстро так или иначе. Производительность не имела значения.
Теперь, когда Закон Гордона Мура изменил направление (больше ядер, а не более быстрых центральных процессоров), компьютеры на самом деле не становятся намного быстрее, таким образом, я ожидал бы, что производительность станет более важным фактором в разработке программного обеспечения (пока действительно хорошая параллельная парадигма программирования не поражает господствующую тенденцию, так или иначе). Существует предел тому, как медленное программное обеспечение может быть все еще будучи полезным, y'know.
Одним из выпусков медленного программного обеспечения является результат большинства разработчиков, использующих очень высококачественные машины с многоядерными центральными процессорами и загрузками RAM как их основная рабочая станция. В результате они не замечают проблемы производительности легко.
Часть их ежедневного действия должна выполнять их код более медленных более основных аппаратных средств, которые будут использовать ожидаемые клиенты. Это покажет производительность реального мира и позволит им фокусироваться на улучшающихся узких местах. Или даже выполнение в VM с ограниченными ресурсами может помочь в этом обзоре.
Более быстрые аппаратные средства не должны быть оправданием за создание медленного неаккуратного кода, однако это.
Да, программное обеспечение в наше время может быть медленнее или быстрее, но Вы не соответствуете как подобному. Программное обеспечение теперь имеет настолько больше возможности, и намного больше ожидается его.
Позволяет берут в качестве примера: Powerpoint. Если я создал слайд-шоу с Powerpoint с начала девяностых, у меня может быть слайд-шоу с симпатичными цветами довольно легко, хороший текст и т.д. Теперь, это - слайд-шоу с движущейся графикой, необычными переходами, хорошими изображениями.
Точка, да, программное обеспечение медленнее, но это делает больше.
То же сохраняется людей, которые используют программное обеспечение. назад в 70-х, для создания презентации необходимо было создать собственные диапозитивы, возможно, даже с помощью пера :-). Теперь, если бы Вы сделали то же самое, то Вы смеялись бы из комнаты. Требуется то же время, но качество выше.
Это (по-моему) - то, почему компьютеры не дают Вам рост производительности, потому что Вы проводите то же количество времени, делающее 'задание'. Но если Вы используете сегодняшнее программное обеспечение, Ваши результаты выглядит более профессиональным, Вы получаете в качестве работы.
Skizz и Dazmogan имеют его правильный.
С одной стороны, когда программисты пытаются заставить свое программное обеспечение взять как можно меньше циклов, они успешно выполняются, и это ослепляюще быстро.
С другой стороны, когда они не делают, который является большую часть времени, их интерес к "Быстрой Общности" израсходовал каждый доступный цикл и затем некоторых.
Я делаю большую настройку производительности. (Мой предпочтительный метод является случайной остановкой.) Почти в каждом случае причиной замедления является сверхдизайн класса и структуры данных.
Достаточно странно причиной, обычно приводимой для чрезмерно событийно-ориентированной и избыточной структуры данных, является "эффективность".
Как Bompuis говорит, мы полагаемся на многие слои абстракции. Это - точно проблема.
Да это сохраняется. Вы дали некоторые видные примеры для противостояния тезису, но принимать во внимание, что эти примеры разрабатываются многочисленным сообществом довольно хорошо осведомленных людей, которые более или менее знают о хороших методах в программировании.
Люди, работающие с ядром, знают об архитектуре другого ЦП, многоядерных проблемах, строках кэша, и т.д. Существует интересная продолжающаяся дискуссия о включении аппаратной поддержки счетчиков производительности в ядре магистрали. Это интересно с 'политической' точки зрения, поскольку существует конфликт между людьми ядра и людьми, имеющими много опыта в контроле производительности.
Люди, разрабатывающие Firefox, понимают, что браузер должен быть "легким" и быстрым, чтобы быть популярным. И некоторым расширяются, им удается сделать хорошее задание.
Новые версии программного обеспечения, как предполагается, выполняются на более быстрых аппаратных средствах, чтобы сделать, чтобы тот же пользователь испытал. Но ли цена справедлива? Как может мы задницы, была ли функциональность добавлена эффективным способом?
Но возвращаясь к основному предмету, многие люди после окончания их исследований не знают о проблемах, связанных с производительностью, параллелизм (или еще хуже, они не заботятся). В течение довольно долгого времени закон Moore предоставлял повышение стабильной работы. Таким образом люди написали посредственный код, и никто даже не заметил, что было что-то не так с неэффективными алгоритмами, структурами данных или большим количеством вещей низкого уровня.
Затем некоторые ограничения сыграли роль (тепловая эффективность, например), и больше не возможно получить 'легкую' скорость для немногих маркеров. Люди, которые просто зависят от аппаратных повышений производительности, могли бы получить холодный душ. С другой стороны, люди, у которых есть всестороннее знание алгоритмов, структур данных, проблемы параллелизма (довольно трудный принять на работу их...) продолжат писать хорошие приложения, и их значение на рынке труда увеличится.
Закон Wirth должен не только быть интерпретирован буквально, также о плохом чрезмерном увеличении размера кода, нарушив правило keep-it-simple-stupid, и люди тратят впустую возможность использовать 'более быстрые' аппаратные средства.
Также, если Вы, оказывается, работаете в области HPC затем, эти проблемы становятся довольно очевидными.
В некоторых случаях это не верно: частота кадров игр и дисплей/проигрывание мультимедийного контента намного выше сегодня, чем это было даже несколько лет назад.
В нескольких aggravatingly общих падежах закон содержит очень, очень верный. Когда открытие окна "My Computer" в Vista для наблюдения дисков и устройств занимает 10-15 секунд, такое чувство, что мы идем назад. Я действительно не хочу запускать любое противоречие здесь, но случалось так, что, а также огромная разница вовремя должен был открыть Photoshop, который прогнал меня платформы Windows и на Mac. Дело в том, что это замедление в общих задачах достаточно серьезно, чтобы заставить меня перейти выход из своей прежней зоны комфорта для ухода от него.