前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >过早优化是万恶之源

过早优化是万恶之源

作者头像
大数据和云计算技术
发布2018-03-08 10:52:08
1.1K2
发布2018-03-08 10:52:08
举报

Don’t Cut Yourself: Code Optimization as a Double-Edged Sword。中文翻译:过早优化是万恶之源。

代码优化的好处多多,但是这并不意味着所有的代码都需要进行优化,有时过度的优化反而适得其反——费时、费力、不讨好。 “现代计算机科学的鼻祖”Donald Knuth曾说过“过早的优化是万恶之源”,因为:让正确的程序更快,要比让快速的程序正确容易得多。文中讲了7个原则,简单罗列如下:

1. 究竟要优化什么? 2. 选择一个正确的优化指标 3. 优化在刀刃上 4. 优化层次越高越好 5. 不要过早优化 6. 依赖性能分析,而不是直觉 7. 优化不是万金油

更详细的大家可以看英文:http://blog.smartbear.com/programming/dont-cut-yourself-code-optimization-as-a-double-edged-sword/

为什么把这个话题拿出来讨论下,因为我现实中发现过早优化,其实是一个非常容易犯的错误。举几个例子:

1、数据库优化中,为了性能优化,放弃通用性,把SQL全部用C语言重写,这种技术是不可能得到发展的。

2、Hadoop领域里面,Tez/stringer为了解决hive性能,只是将M/R通过DAG作业来替代,将多个作业用一个作业来替代,减少中间过程。但是实际上hive用在查询上,除了M/R效率底下外,还有进程启动代价太高,以及最主要的是数据存储不是专门为分析场景准备的。所以我预计如果Tez/stringer只是按照目前的思路优化,最后肯定昙花一现。

3、Shark,hive on spark。简单的将hive拿到spark上来,从最新资料来看,DataBricks 已经被放弃了shark,转而将重心放到 Spark sql上面来。

不要为了优化而优化,优化应该先做好顶层设计,再落地到具体的技术细节,否则优化出来的东西,不会有长久的生命力。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2014-11-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 大数据和云计算技术 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据保险箱
数据保险箱(Cloud Data Coffer Service,CDCS)为您提供更高安全系数的企业核心数据存储服务。您可以通过自定义过期天数的方法删除数据,避免误删带来的损害,还可以将数据跨地域存储,防止一些不可抗因素导致的数据丢失。数据保险箱支持通过控制台、API 等多样化方式快速简单接入,实现海量数据的存储管理。您可以使用数据保险箱对文件数据进行上传、下载,最终实现数据的安全存储和提取。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档