|
锁定老帖子 主题：看高手代码--从小case学大道理
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-06-01
sw1982 写道 做业务和玩编程不是一个概念。如果你觉得计算几个hash也是性能浪费，真不如去汇编得了。
你可以尝试量化一下， 而且架构师通常会建议“先抗住再优化”，而《重构》这本书自身都建议，不到万不得已，不要优化代码的技巧！ skydream 写道 sw1982 写道 ...lookup 一下hashmap真的那么低效吗？ 建议复习下数据结构哦，你这些总结是没错，可是很表面
典型的没有写过高并发程序的思维方式，明明可以节约的地方，仅仅几行代码就可以优化，偏偏不做。 hashmap再快，也比case 一个 整型满上1w倍。 性能，是一点一点挤牙膏挤出来的，哪能到处浪费啊。 
好像还说遇到switch case 就是bad smell。是可以重构的地方。。 建议使用strategy或者state pattern 替换之。 |
| 返回顶楼 | |
|
发表时间：2010-06-01
sw1982 写道 我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。
你面试的人在项目中是需要去作优化还是叶公好龙? 对一个以前只作业务开发的人来说不优化才是好程序员 如果你认为程序员时间比分布服务器价格更贱的话.... 我也没有办法. |
| 返回顶楼 | |
|
发表时间：2010-06-01
sw1982 写道 我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。
同意你的说法，我也是之前从计算机基础书上看到，DRAM比磁盘快十万到百万倍，才改变了以往频繁操作DB的习惯，因为访问DB需通过网络，而网络比磁盘又得慢四到五个数量级。这样，在内存中无论多SB的操作(乱七八糟，没有任何优化的代码)，也比访问磁盘和网络效率高好多。所以，优化不优化代码与业务对效率的要求有关，但知道这些效率比，对我来说，写程序时改变很多坏习惯。仅是个人理解。 |
| 返回顶楼 | |
|
发表时间：2010-06-01
最后修改：2010-06-01
langyu 写道 sw1982 写道 我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。
同意你的说法，我也是之前从计算机基础书上看到，DRAM比磁盘快十万到百万倍，才改变了以往频繁操作DB的习惯，因为访问DB需通过网络，而网络比磁盘又得慢四到五个数量级。这样，在内存中无论多SB的操作(乱七八糟，没有任何优化的代码)，也比访问磁盘和网络效率高好多。所以，优化不优化代码与业务对效率的要求有关，但知道这些效率比，对我来说，写程序时改变很多坏习惯。仅是个人理解。 欢乐 |
| 返回顶楼 | |
|
发表时间：2010-06-01
sw1982 写道 我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。
请问你是怎么对比的。 顺序读硬盘是100多M/S吧。 内存是nG/s吧？ 这有个数量级对比了吧。 具体怎么算，oracle trouble shooting是里面有个计算公式。我没记住。 请问你是怎么算的？ |
| 返回顶楼 | |
|
发表时间：2010-06-01
抛出异常的爱 写道 langyu 写道 sw1982 写道 我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。
同意你的说法，我也是之前从计算机基础书上看到，DRAM比磁盘快十万到百万倍，才改变了以往频繁操作DB的习惯，因为访问DB需通过网络，而网络比磁盘又得慢四到五个数量级。这样，在内存中无论多SB的操作(乱七八糟，没有任何优化的代码)，也比访问磁盘和网络效率高好多。所以，优化不优化代码与业务对效率的要求有关，但知道这些效率比，对我来说，写程序时改变很多坏习惯。仅是个人理解。 欢乐 你的评论怎么改了。 抛哥，看看我下面的言论有什么不当的， |
| 返回顶楼 | |
|
发表时间：2010-06-01
的确，不管怎样，这样的设计方法是值得学习的
|
| 返回顶楼 | |
|
发表时间：2010-06-01
mathfox 写道 抛出异常的爱 写道 langyu 写道 sw1982 写道 我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。
同意你的说法，我也是之前从计算机基础书上看到，DRAM比磁盘快十万到百万倍，才改变了以往频繁操作DB的习惯，因为访问DB需通过网络，而网络比磁盘又得慢四到五个数量级。这样，在内存中无论多SB的操作(乱七八糟，没有任何优化的代码)，也比访问磁盘和网络效率高好多。所以，优化不优化代码与业务对效率的要求有关，但知道这些效率比，对我来说，写程序时改变很多坏习惯。仅是个人理解。 欢乐 你的评论怎么改了。 抛哥，看看我下面的言论有什么不当的， 每秒事务的个数 用来作性能测试 如果没有测试目标 那个值是没用的. 当然如果有了测试目标 还要确定主要修正范围 作这个范围的review 确定需要修正点. 并给出假想方案的性能提高可能值 (一般这时会写demo.否则谁能凭空猜出这东西能快几毫秒) 最后如果被审批下来 (80%是不能被审批.....再找方案) 痛苦才刚刚开始 |
| 返回顶楼 | |
|
发表时间：2010-06-01
抛出异常的爱 写道 langyu 写道 sw1982 写道 我面试过好几个人，全都是“靠感觉”。大家都知道内存cache效率高过磁盘IO,但是高多少数量级，你有概念么？ 这个概念都没有，谈什么优化优化。
同意你的说法，我也是之前从计算机基础书上看到，DRAM比磁盘快十万到百万倍，才改变了以往频繁操作DB的习惯，因为访问DB需通过网络，而网络比磁盘又得慢四到五个数量级。这样，在内存中无论多SB的操作(乱七八糟，没有任何优化的代码)，也比访问磁盘和网络效率高好多。所以，优化不优化代码与业务对效率的要求有关，但知道这些效率比，对我来说，写程序时改变很多坏习惯。仅是个人理解。 欢乐 是挺欢乐的 计算机机上书的那个数量级，至少会让我建立起对内存/磁盘/网络缓存模型的感性概念，避免在代码中犯幼稚的错误。到具体应该中，是得评估是否需要优化及优化的质量。 之前做过的web项目就有响应时间的大概要求，在写好代码后，边重构边测试性能瓶颈点，加以简单的优化，这没什么不对吧。不同的应用有不同的需求，况且楼主所说的还得需要提供大量服务，几行代码就能搞定的优化，有必要陷入到与程序员及项目时间的讨论吗。 在讨论问题时，有没有意见都可以指出来。都是做技术的，对那个数量值有意见，那我回去再查下，可能我也记错了。而不是抛出两个字，表明你不屑的态度。 |
| 返回顶楼 | |
|
发表时间：2010-06-01
sw1982 写道 ...lookup 一下hashmap真的那么低效吗？ 建议复习下数据结构哦，你这些总结是没错，可是很表面
看来你没有认真阅读 |
| 返回顶楼 | |
