| |
|
|
| 首页 淘股吧 股票涨跌实时统计 涨停板选股 股票入门 股票书籍 股票问答 分时图选股 跌停板选股 K线图选股 成交量选股 [平安银行] |
| 股市论谈 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
| 商业财经 科技知识 汽车百科 工程技术 自然科学 家居生活 设计艺术 财经视频 游戏-- |
| 天天财汇 -> 科技知识 -> 程序中提升几毫秒、节省几 kB 的内存有必要吗？ -> 正文阅读 |
|
|
[科技知识]程序中提升几毫秒、节省几 kB 的内存有必要吗？ |
| [收藏本文] 【下载本文】 |
|
我在写程序的时候,更改一个判断语句,会提升几毫秒,换一种方法会节省几KB，这些有必要吗？这些都是公共方法,我很费解啊，请大神解答。 |
|
Profiler扛旗人不在知乎了… 这种问题，从来都不是这么缺信息问的。 就好比你问我，一个零件便宜一分钱，值吗？ 那得看零件是啥。 一台火箭发动机省一分钱，谢谢，下次不用了，您该忙啥忙啥去吧。 一个螺丝省一分钱，大哥，慢慢搞别急，省不出一分给我省半分也行。 程序里也是。一个总共运行一次的函数，省了几毫秒；一个全世界可能只需要一份拷贝的数据，省了几kb。那当然是没必要。 但如果是比如内核里的每秒调用几万次的函数，别说省一毫秒了，省一个时钟周期都值得考虑一下。或者大量拷贝的数据结构，比如线程场景，那省一个字节也值得考虑一下。 判断你的程序的调用模式的工作叫Profiling（具体含义翻译成中文挺难说清楚的，贴个英英字典链接：Definition of PROFILE）。当然实际要考虑的也并不总是总共省多少时间之类的事情，还有比如关键路径上的考量等等。但总之， 先Profile，再优化。 |
|
若干年前我把公司算法由处理一帧20ms，优化到5ms。服务器一块计算板原先只能跑20路，优化后跑60路，除了硬件成本下降。甲方的占地，功耗，空调，维护费用，故障大幅度下降，直接把竞争对手打到阴沟里去了，公司年终给了一辆车，当然 是太抠门了。后面换工作也都是这种优化工作。将 各种算法在arm，DSP上优化实现。 实现算法原型其实不难，难得是如何实现以及在市场上竞争力。 |
|
前几天听一个科普节目，讲了人们反编译了80年代的任天堂的麻将游戏的故事。 这游戏不光实现了麻将这个游戏，可以人机对战。 还有不同的难度 反编译的前，人们特别好奇如何眼红几十K的容量做了一个这样的游戏，图形压缩还好理解，都有方案，但其人机对战打牌的人工智能怎么实现的？？？ 最后发现，其实这款产品根本就没有考虑人工智能，程序对手在初始的时候就生成了一幅可以听牌的牌，然后然后随机一个步数，后就胡牌。不同的难度随机的步数就不一样。 简单吧。但就是能给你你在和对手打牌的感觉。 不要低估人类的智慧，几K内存都无法锁死他们。 回答你这个题目。 我的回答是， 代码架构决定产品的性能上限。 但每一行代码决定产品的下限，而一行代码的差别可不止几毫秒。 如果你下限不高，上限再好也是白搭。 |
|
微信的开发小组明显认为是不必要的 |
|
提问者显然对于数量级没有任何概念，进而可以推出其实没有正儿八经的做过性能调优。 比如说更改一个判断语句能提升几毫秒…… 这么说吧，通常纯计算的东西，超过一毫秒就算是计算量巨大。 我做的某个微服务，从接收请求到输出响应，经历http://ASP.NET Core框架的几十个方法，创建数百个对象，整个过程也不超过1ms。 你特么改个判断能提升几毫秒， 要么是你做梦，要么是这代码写的实在太差了…… |
|
针对一个复杂系统的性能优化工作，有一个顶级思维，就是Amdahl's Law(阿姆达尔定律)。 Amdahl's Law的核心思想就是当我们加快系统的一个部分的速度时，对系统整体性能的影响依赖于这个部分有多重要和这个部分优化的程度。 假设一个系统运行的消耗为 Told" role="presentation">ToldT_{old} ,现优化了其中占比为 α" role="presentation">α\alpha 的一部分的消耗，性能提高k倍，则现在整个系统运行的消耗 Tnew" role="presentation">TnewT_{new} 为 Tnew=(1−α)Told+(αTold)/k=Told[(1−α)+α/k]" role="presentation" style="font-size: 100%; display: inline-block; position: relative;">Tnew=(1?α)Told+(αTold)/k=Told[(1?α)+α/k]T_{new}=(1-\alpha)T_{old} +(\alpha T_{old})/k = T_{old}\left[ {(1-\alpha) +\alpha/k}\right]\\ 整个系统优化比例 S" role="presentation">SS 为 S=1(1−α)+α/k" role="presentation" style="font-size: 100%; display: inline-block; position: relative;">S=1(1?α)+α/kS=\frac{1}{(1-\alpha) + \alpha/k}\\ 假设一个系统有一个模块消耗了80%的资源，性能仅仅提升了1.1倍，则整个系统性能提升了1.078倍。 如果另一个模块消耗了5%的资源，性能即使提升了10倍，整个系统提升的倍数为1.047倍。 假设这两个模块的复杂度以及优化难度是一样的，那么你会选择优化谁呢？ 在实际的优化工作中的指导意义就是优化之前先做Profile，甚至是造Profiler，能够准确定位出消耗的大头是优化性能的关键，剩下的就是拼基本功了。 Reference [1] 阿姆达尔定律 - https://zh.m.wikipedia.org/zh-hans/%E9%98%BF%E5%A7%86%E8%BE%BE%E5%B0%94%E5%AE%9A%E5%BE%8B [2] Computer Systems A Programmer’s Perspective, Chapter 5 |
|
5ms->1ms，提升巨大简直逆天 60s->59.99s，可能没有必要改 |
|
当你理解循环的威力时，你就会知道有多可怕了。 |
|
如果你希望玩到60帧每秒的游戏，不考虑多线程，那么开发者每帧能用来做逻辑与运算的时间只有16毫秒，2毫秒就是所有计算时间空间的8分之一。这个感受直观了吧 |
|
万能回答：It depends! （不一定） 自己写hello world来学习一门语言，不要说提升几毫秒、节省几KB，你能够把hello world造出耗费一分钟、多占好几M，那说明你折腾得够深，学得也越多。 写一个单机程序，一个按钮的响应时间提升几毫秒，节约几KB，意义不大，人是感觉不到几毫秒的延迟差异的，如果写出来的代码更清晰，宁可多耗费那几毫秒吧。 写一个通用函数，要被很多地方调用，那提升几毫秒意义比较大，因为一次调用虽然只有几毫秒，但是调用1000次就会有上秒的代价，这也就是某些基础通用函数要使劲优化的原因。 写一个有每秒几万请求的大型服务器软件，节省几KB意义比较大，因为能够节省很多内存使用，节省几毫秒，那也depends，如果是做基础框架，去优化这几毫秒有意义，但是对于做应用层开发，也许网络请求本身就消耗几百毫秒，你这费劲优化几毫秒，要想想投入产出比。 总之，一切要依据实际情况来定。 关键问题是——你有优化这几毫秒几KB的能力吗？ 你能吗？ 具体情况可能不用优化这几毫秒，也可能要求优化这几毫秒。 从个人角度，先不要说有没有必要，您有这能力吗？ 有了这能力，你就不用纠结了。 |
|
会重复执行的运算，省1us都很重要，比如视频处理，比如网络报文处理，比如图表绘制时的获取数据。 会有大量副本共存的数据，省一个字节都很重要，比如QCustomPlot那扯淡的32字节存一个点。 不会重复执行的运算，只有在需要提升用户体验降低延迟时，才需要花心思优化速度，比如保存读取初始化释放。 没有副本或共存副本很少的数据，易用性大于节约内存，比如ffmpeg的av_frame里，除了图像数据还有几十个字段，还有N个字段甚至是指向另一个庞大的结构体，恨不得把一个视频帧的所有信息所有上下文全塞进去。 |
|
根据我做了十多年商业系统的经验，这不是一概而论的。 但凡无脑说有的，大多是没有大型商业软件经验的。软件架构最重要的是 恰当。 软件的overdesign也是要计较的。所以软件当中，哪些应该快，哪些可以不快，都是有讲究的。 乃至于一个系统，上百个接口，哪些接口重要，哪些接口不重要，也是有分数的。 比如一个photoshop，保存文件的时候，提升一秒，这没有意义。但是12306查询提高一秒，就是划时代的。 excel每打开一个工作表节省1MB，没有意义，但是，ffmpeg处理每帧节省10KB就是重大变化。 总的来说，要看的就是峰值时，你的提高，节省，占全量的比例。 但是，这个思想很重要，很多人在写代码的时候，没有节约的思想，写出来的代码性能就会差很多，主要是写的人，可能并不直到运维最后会面对什么流量。 所以，应该做的是，在任何时候，都在心里保持“优化”的思想，但是在实践上，要看看“优化”是否overdesign |
|
我曾经改进了一个Foreach的算法, 节省了大约不到1毫秒的时间 然后这个foreach会循环一万多次, 曾经的程序卡顿瞬间没有了, cpu也下来了不少 你说有必要么? 公共方法, 要的就是极致的性能和可靠性, 因为你不知道业务会怎么去玩他 但是也不尽然, 很多时候, 用响应时间和内存, 去换代码清晰易读, 也是很有必要的, 这种抉择的依据, 就不是一两句能说清楚的了, 这也是很多码农值钱的原因之一 |
|
妈蛋我millies micros到底哪个是毫秒哪个是微秒。。。 我们最近对某个函数进行改动，用到了一个四舍五入的调用不够优化，导致这个函数慢了大概两个micro。 这个函数每次市场有数据过来，每个货币对都会被调用20到40来次，也就是这个问题会耽误到40到80micro。 市场忙的时候，大概每个millies会发过来四五个数据包，每个包大概5到15个货币对不等。 因为市场数据处理很多时候不能并行化，所以一旦耗费的时间超过两三百micro，就会造成拥堵。也就是说，在第一个数据包处理完以后系统就可能产生拥堵。 来在市场忙碌的极端情况下，这种拥堵会系统在处理这个millies内的最后一个数据包时已经是4、5个millies以后的事儿了。然后忙碌的市场持续个两三百millies就会造成秒级拥堵，如果继续持续忙碌半分钟，就能造成分钟级的理论延迟。 然后最近的外汇市场正好就非常忙碌。微观情况下持续几百millies的繁忙会非常常见，持续几秒、几十的高频数据也不是不可能。 任何一家大型做市商在忙碌的市场下慢个几秒钟就足够造成几万甚至几十万美元的亏损了，更何况接近分钟级的延迟。。。 当然增加这两个Micro的改动在函数上线前被揪了出来，没有造成什么损失。 |
|
有啊，你一个60帧的游戏，每帧的预算就是16.6ms。你要是单帧提升8ms，直接干到120帧去。 内存主要看你预算有多少了，你要是一个对象减少几kb，一万个对象就是10M啊，移动平台10M很关键的好不好 |
|
玩游戏： 60 帧的间隔是 16.67ms。120 帧的间隔是 8.33ms。 如果你有能力随随便便就提升几个毫秒…… |
|
最近在做项目优化，刚好可以说一下。 我们项目是在手机上以30帧运行的。也就是说我们在一秒钟要能够做三十次刷新，分配给每一帧的时间就是33ms。 我们大型团战时玩家模型，动作数据，特效播放，数据包发送与接收，业务逻辑处理，音效播放，战斗飘字，文本提示，角色寻路，ai，ui，物理计算，渲染，等等各个模块加起来的耗时不能高于33ms。你的模块占用的越多，留着其他系统的时间就越少。且并不是达到33ms就可以了，我们还需要兼容性能较弱的低端手机，也尽量不要让运行帧率在风险值徘徊，尽量缩减它，以保证不会出现偶发掉帧。 另外一个，当写完一个接口需要考虑这个接口的使用频率。比如我们当时有个查找子物体的接口，单纯一次搜索只有0.1ms，20b gc。 看上去没什么问题，但是这个接口在所有ui上都会用到，访问的次数多的时候几千次，占用耗时多的时候达到了200ms，掉帧非常之狠。 做性能优化之前需要判断性能消耗的点在哪，看到游戏在真机上跑不满30帧，先用profiler调试。如果是c#逻辑导致的耗时可以优化具体耗时逻辑，还可以降低batches，降低cpu的压力。如果发现cpu大部分时间都在等待gpu绘制完成（看看是不是有个.waitxxxfps的函数占用过高），如果是的话，在渲染进程确认下渲染函数，如果耗时过高就能定位是渲染压力。那么就降低setpasscall减少gpu状态切换，检查模型网格数，检查纹理压缩，优化耗时shader，降低overdraw，检查全屏计算的后处理等。 提示一点:比如高斯模糊，是可以将rendertexture分辨率缩小到之前的1/2甚至1/4去绘制的。如果分辨率只有之前的1/2，可以减少75%的像素绘制，如下图 |
|
|
但也不意味着我们所有模块都必须要抠的这么死，比一个ui界面逻辑，自己的界面打开时耗时稍微有一些但不大，如果需要花很大的时间成本优化耗时，在堆量期可以先搁置，毕竟它不会影响主线流程。 关于优化的几个建议： 注意GC问题，经常复用的对象建议缓存起来，实例化会耗时，置空后会成为垃圾内存等待GC时清理，垃圾内存越多，GC越频繁，它会使程序瞬时卡顿。 能在编辑器环境中处理的问题，尽量在编辑器中处理。如unity组件，在编辑器中事先添加比运行时添加性能高蛮多。 在初始化时构建hash表，取数据时直接获取值，减少每次取数据都循环，加快查找速度。 Lua做热更新的项目，配置表建议直接使用lua文件存储，目前解析速度最优。（希望有其他更优建议探讨） 在场景切换时清理掉垃圾对象，并主动触发GC。保持干净的环境进入下个场景，使游戏更流畅 100个1kb的资源和1个100kb的资源加载速度100kb的要快太多，所以把碎片的资源打成一个包，加载效率会更高 在现代的硬件中drawcall性能消耗没那么大了，多关注setpasscall，它的消耗是drawcall的七倍不止 推荐使用Lua Profiler做lua代码性能分析 在发现真机掉帧时，不要盲目优化，先确定 分割线================= 转图形程序了 讲个小知识，在写着色器代码的时候，应当尽量避免使用if语句，这个跟gpu架构有关，if语句会影响gpu的并行效率。即使有，也改成keyword，在打包时，会将不同着色器代码分支分别生成变体。不同的keyword有不同的逻辑。 图形块需要注意的优化：卡顿来自于setpasscall过高，overdraw，显存带宽不足（检查下纹理是否过大），定点数过多，全屏绘制过多。 Setpasscall过高就注意合批方案 Overdraw过高就使用pre-z优化alphaclip，减少半透明物体绘制 显存带宽占用过多就压缩纹理大小 全屏绘制过多，如果是urp中自己写的后处理，就仿照urp自带的后处理，使用swap减少纹理拷贝次数 Shader代码复杂度过高就优化代码，具体的内容比较多，网上可以找到蛮多的 没想到这么多人看，嗯，放一下我的个人博客，写的很乱很杂，可以捡一些有用的再补充下相关知识，希望有用。http://www.fangmujun.cn |
|
GTAV程序员：嗨，我就说没啥优化的必要 |
|
|
|
|
先说场景， 1。嵌入式设备，内存小，处理器慢。几KB很宝贵了。几毫米也很重要。 2。视频编解码。假设每秒30帧，留给你每帧处理的时间很紧张的，你每帧慢几毫秒，累计起来就会卡顿。 3。图像处理，动画处理。都是要求越快越好。 4。电子签名，鼠标手势。慢几毫秒你都会觉得轨迹跟不上。 5。浪费几KB，如果是放在LIST，MAP等容器的内容，而数据巨大，内存差异就出来了。之前设计过一个文件检索工具，索引项正常占了上G的内存，经过优化设计，比如大量的标识用BIT存储，逐个字节，逐个BIT设计。内存占用降到了十几MB。 而且明明不需要浪费的，为啥要浪费呢。一般看到能更合理的优化方案，一定选最优的。 最朴素的，就算农民秋天能收几吨的粮食，看到地上散落的麦穗一样会捡起来。 |
|
只要不存在内存泄漏 or 影响运行效率（大量对象拷贝导致运行速度变慢、cpu 负载升高、单机 qps 承载能力下降），一般几 kb 的内存没啥人会关心。 但几毫秒就不一样了。 以推荐/广告系统为例，整个请求的响应时间基本要控制在 500ms 以内，而上下游至少还要经过召回、粗排、精排、重排的模块，每个模块可能涉及到十几个甚至几十个 rpc 服务，比如精排模型的在线推理 rpc 响应 pct95 一般不会超过 100ms，平均大概在 30ms（各家不一样，数量级大概是这个）。你要是能通过简单的代码更改，让 33ms 降到 25ms，那理论单机 qps 就从 30 涨到了 40（计算密集型的，就先不考虑并行了，打个比方），相当于之前承接 1 万 qps 的流量需要 333 台机器的话，现在只需要 250 台，即使是对于一个资深架构大佬，这也是值得写到年终述职的 ppt 首页的一个优化。 |
|
你将来在高速行驶，放开方向盘在车里打个盹的时候是希望防撞系统延迟500毫秒还是1毫秒? 假设你开50km/h，不算快吧，半秒钟和1毫秒内踩刹车可能就是生死之别，对对方的汽车也是一样，半秒内自动规避和1ms内自动规避也是生死之别。 但就是个普通网页程序，who cares。 |
|
之前在腾讯的维护一个老业务，就是将数据从db 放到 redis， 分片后，单个任务需要操作redis, db 总次数在130w次， 有一次机房裁撤，业务代码改到同城市的其他机房， 平均每次多了4ms，服务执行时间比之前多了一个多小时。 130w*4ms= 520w(ms)=5200s |
|
一般没必要。除非针对这个卡顿进行了专题攻关。 只要没有专门的性能评测（profiler）决定某段代码需要优化性能，那么就没有必要优化。 另外，永远不要以为自己比编译器聪明。开编译器优化比什么都重要。 如果你的某段代码导致了编译器优化选项打不开（对C++来说这并不少见），那么确实是一定要改的。 以上的意思不是说优化无用，而是说：在没有有效的评测手段前提下，你以为的优化很可能实际上并没有真的实现优化，改来改去在编译器看来有可能都是等价的操作。 但凡你想要优化，首先写下性能评估与测量的代码，再进行优化，这时你才能真正意识到什么样的优化是有价值的。 |
|
多年前我问欧洲某汽车品牌工程师： “为什么全球各主机厂都要那么抠油耗？用户缺那一点点油钱吗？” 工程师说：“每年出厂数百万台主机，一用几十年，我们多抠一点，就会给后人多留点。” |
|
答案是：看成本。 如果是在不提高成本的情况下，提升几毫秒，节省几KB，我觉得是白捡，顺手拿起，何乐而不为。 如果是在牺牲软件的结构和可读性的情况下，一般是没必要的。 源代码最重要的是给其他人看懂，要在软件架构和效率中拿一个取舍，当然能同时提高两者是最好，但有矛盾的时候，我是优先选择代码的架构整洁干净，而不是节省几个kb的内存或者提高几毫秒的运行效率。 一点点提高运行效率和节省内存的事情，交给编译器和系统可能更靠谱。如果要提高很多效率和节省大量内存，对结构的整体优化和重构是更好的选择。 |
|
有必要，可以用资源的角度来分析三个阶段的意义。 在一个程序刚被设计出来时，做的是从0到1的工作。使得人们看到希望。对初创期的创业公司也是如此。意义在于希望。相对于还没有这个程序或产品时，提升的倍数可能很大，但总额却很小。 随着程序的使用，部署量增大，无论是在更多人的电脑还是更多的服务器。就像创业公司进入了发展期，只要多投钱就能线性的见到成果。努力能见到成比例的回报，是所有人都希望见到的。 随着应用和需求大多被满足，就进入了成熟期。此时继续的努力带来的直接收益就很小了。但通过减小浪费，则可以使得不继续投入资源的情况下的收益得以提高。 题主的问题，对应的就是成熟期。举一个例子，2008年国内的架构师群体追求的两个顶级目标，一个是单WEB服务器千万PV，另一个单聊天服务器千万并发连接。后者就需要在节省资源上下很大的功夫。千万并发连接，需要使用很多内存，以标准的Linux TCP协议栈为例，单单是收发buffer就需要占用8KB的内存，千万并发连接的buffer就需要占据80GB的内存空间。而那个时代的服务器普遍还是2-4GB内存，为了实现这个目标。架构师就普遍使用新的缓存策略，在仅仅是等待而没有通信的连接上不保留专用的buffer，而是让所有连接共用一个buffer池，同时优化连接管理部分的结构，优化通信对查找的策略。才能勉强在只有4GB内存的机器上维持千万并发连接。 举一个更容易理解一点的例子。假设一个电动机，消耗功率为1000W，效率为95%。那么就会有50W的热功率。应用空间限制了散热功率很难改变。但如果通过一系列优化，使得效率提高到98%。看起来只是提高了一点。但相同50W热功率的情况下的总功率却可以提升到2500W。这就是典型的降低资源损耗而成倍提高系统效果的原理。 刚才解释了节省一点点内存，就可以使得并发急剧提高。再说说题主问的提高几个毫秒。假设一个请求以前的处理时间是10mS，处理时申请的内存包括本地变量、全局变量、数据库连接、网络连接、文件资源等等，占用的内存为100MB。那么在服务器只有1GB的情况下，处理容量上只能允许有10个请求在并行处理。1秒时间里只能处理完成最多1000个请求。但如果将处理时间降低为5mS，那么就可以1秒时间里完成最多2000个请求。提升还是非常巨大的。 总的来说，在细微处追求极致的资源占用降低，可以使得在总体资源不变的情况下，加大的提高系统的处理能力。这在系统的成熟期是有很大意义的。 |
|
最近把速度优化到100毫秒以内了 |
|
|
放一个典型的现场图，要把带卷中心定位准，然后控制带卷先平移，再下降到基坑底，再平移到开卷机上。带卷中孔和开卷机转轴的间隙仅有±1.25cm |
|
|
带卷往开卷机里穿入 再更新下，上上周（八月初）已经实现了基于单目视觉的自动上卷，控制过程非常可靠，比一般工人上卷效果更好。现在的工作是进一步完成全自动上卷，以后工人按钮启动后，运料车自动移动到钢卷下面，移动到开卷机，开卷，将带卷送入轧机后自动开始冷轧 最近在做个东西，在轧钢厂用单目视觉跟踪钢卷，控制它移动并且穿入转轴中。因为环境比较复杂，得把CNN和经典算法组合起来，才能获得准确可靠的跟踪定位数据。但是计算量大了，处理速度就变慢，会出现滞后，造成控制不准确。这周花了不少时间，找出整个过程中的效率瓶颈然后想办法减少耗时。 首先是消除重复性计算，比如两个算法都要对图像做一样的预处理，那就在外面先做好，然后传递给两个算法。 然后是减少不必要的计算范围，比如对600*600区域做计算，仔细分析发现只需要550*550，减少一部分计算时间。 用多线程把串行过程尽量并行化，比如摄像机一个线程，计算一个线程，硬件通信一个线程，界面显示一个线程。 优化代码，程序是python写的，把所有的计算想尽办法用numpy等实现，尽量不写循环 目前把一个控制周期的耗时从三百多毫秒减少到一百七十毫秒左右，控制效果改观很大 还在琢磨压缩时间，哪怕再能减少十毫秒也会有好处。比如看看怎样让进程完全独占一个cpu核，减少其他进程切换带来的时间不确定（有时程序的计算耗时会显著增大）。把神经网络再优化下，减少计算耗时。等等 很多人在纠结cpp，认为cpp能够显著提高计算速度。可以看下stackoverflow里面的评论 |
|
|
python程序仅仅是直接调用opencv，或者用numpy做大规模的向量和矩阵计算，基本上没有循环，有十处左右的分支。这种情况下，cpp的效率有提升，但肯定做不到显著提升，几个毫秒最多。我用opencv的随机森林边缘提取算法对625*625*3图像做边缘提取，大约耗时40毫秒，难道python调用一下函数就要几十毫秒不成？ |
|
今天刚纠结怎么把一个模块的RAM消耗降低10kb，没想到就推给我这种问题...... |
|
有。 我最开始脱离无意义练手代码的时候，用的是文曲星当作开发平台。 内存…… 一共是16K。 其中，8K是用来存代码段、数据段的。 即可用的内存其实是8K。 和现在只有空间换时间不一样， 当时时间和空间一样重要，甚至很多时候，空间更重要。 节省几KB，重要不重要呢？ 以那个时候走过来的经验说一句。 提升几毫秒，节省几KB，不是你交给领导、客户的答卷。 那是程序员交给自己的答卷，是我们存在，并且可以持续存在的意义。 ========= 我是一个在交付代码的时候，会写： 但绝对不能接受自己写 的人。（后者应该直接写sum = 5050) |
|
来点不一样的？ 从IC设计的角度来看看，狠有必要。 按照最新4/6nm的工艺，SRAM的density大概是2MB/mm2（不同厂家的IP稍有差异），那么，你每段程序能节省几kB，多个地方就可以节省很多kB。不要小看这几kB，一个当前普普通通的SoC里，可不仅仅data和instruction的cache，有很多.很多.很多的SRAM，几十MB级别。当你能总体节约1MB的时候，那可就是实打实的die面积，也就是实打实，最直接的成本。 关于能提升几个ms的执行效率，更有必要了，做芯片就是ppa的balance。power, performance, area。SRAM最直接的就是area，那执行效率可就是pp了。执行效率高了，core, 总线, peripheral等等的速率都可以降低，就是可以省功耗。这也是实打实的卖点。 所以，如果你的程序做的足够好，那芯片里的trade off可就没那么难了。 当然了，一个i++可能确实没什么提升空间了，但是，做算法的，尤其是芯片的低层算法。就要扣这0.1个平方毫米的面积减少和这个0.1MHz的执行效率提升。 |
|
|
| [收藏本文] 【下载本文】 |
| 上一篇文章 下一篇文章 查看所有文章 |
|
|
|
| 股票涨跌实时统计 涨停板选股 分时图选股 跌停板选股 K线图选股 成交量选股 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
| 网站联系: qq:121756557 email:121756557@qq.com 天天财汇 |