вступление
На самом деле, я давно хотел написать эту статью, в этой статье не будут задействованы какие-либо знания по оптимизации производительности, а просто будет обсуждаться, что такое оптимизация производительности и почему производительность терминала сейчас такая мощная.
В настоящее время такие мощные терминальные аппаратные устройства, как десятиядерный или двадцатиядерный ЦП, высокоскоростная память и благословение на твердотельный жесткий диск, все еще нуждаются в оптимизации для повышения производительности? Я часто слышу, как многие фронтенд-программисты говорят, что после написания кода просто дайте устройству поработать, но смена карты — это все устройство? Или кого сейчас волнует оптимизация производительности, как это может быть так очевидно за десятки миллисекунд?
Сегодня мы обсудим эти вопросы объективно, нужно это или нет.
что такое производительность
Проще говоря, производительность можно понимать как результат многомерных справочных показателей.
Первое, что нужно сделать, это производительность ЦП , Что касается размеров подразделения, общий ЦП будет относиться к нашему тактовому циклу, количеству ядер, количеству потоков, емкости кэш-памяти L3 и эффективности планирования .
Затем идет память.Показатели памяти есть не что иное, как полоса пропускания и пропускная способность данных, передаваемых в единицу времени.На самом деле показателей у памяти много, поэтому я не буду их приводить для экономии места.
Графический процессор, как правило, графическая карта, также может называться сопроцессором.Он в основном выполняет некоторые простые вычисления и помогает центральному процессору выполнять некоторую работу по рендерингу графики.Самое большое преимущество заключается в том, что он может обрабатывать данные одновременно, что сильно отличается от линейной обработки. метод ЦП.Графическая информация может обрабатываться более эффективно, тем самым улучшая частоту кадров и эффект отображения.
Для пользователей, с точки зрения взаимодействия, наиболее интуитивно понятным проявлением производительности является наличие явного пропуска кадров или задержки в работе. Если зависание будет особенно явным или первый экран будет загружаться более трех секунд, это приведет к потере 90% пользователей, что смертельно опасно.
Нужно ли еще оптимизировать высокопроизводительный терминал?
Хорошо, начнем сегодняшнюю тему, на этот вопрос приведем пример:
Предположим, у нас есть память 128 КБ и нам нужно прочитать все данные в памяти.Мы предполагаем, что процессору требуется 0,1 мс для обработки 1 КБ памяти.В качестве примера возьмем псевдокод:
const Memory = new Array(128);
for(let i = 0; i < Memory.length; i++) {
/** 需要 12.8ms **/
}
复制代码这种线性的循环操作对我们来说最平常不过了，也就12.8ms的时间，用大O表示法的话，可以表示为O(n)，目前看起来问题并不大。那么我们换一种写法：
const Memory = new Array(128);
for(let i = 0; i < Memory.length; i++) {
for(let j = 0; j < Memory.length; j++) {
/** 需要 1638.4ms **/
}
}
复制代码这次双重循环（比如冒泡排序）结果或许会有点明显，大O表示法为O(n ^ 2)是原来的128倍，达到了1638.4ms，其实在刷新频率为60Hz的屏幕上，每一帧的时间仅为16.7ms，如果没有通过异步处理的话，已经会造成卡顿了（其实时间并不会这么长，只是假定条件）。那三层循环呢？就会达到O(n ^ 3),时间就会达到209715.2ms；
由此结果可想而知，如果我们电脑内存8GB的情况下，在用这种方式去处理，没有做一些优化的话，简直不敢想象，就算没处理1kb的时间是0.01ms的效率， 也不会有什么明显的改变吧？因为CPU发展至今，性能始终是线性增长的，可我们一段不好的代码，导致的性能问题将会是以指数形式增长的，远远超过我们目前硬件技术的发展；
总结
其实今天想说的问题很简答，性能优化无论在任何时候都是有必要的，比如前端目前新出的一些API，活着任何开源的框架和应用的迭代，都没有忘记在不断的对性能进行优化，其实优化性能的同时也是对自己技术的一个提升，希望无论是前端还是后端的小伙伴，都希望重视起来，写出一段烂可能只需要一个小时，写出一段优秀的代码可能需要十倍二十倍的时间去打磨。