代码优化

3 月，跳不动了？>>> 目的 随着数字经济时代的到来，越来越多的应用依赖数据分析来挖掘数据的价值。作为大数据存储、在线分析的重要基础系统，分析型数据库（OLAP）为数据价值的在线化提供重要的技术平台。 阿里巴巴OLAP团队经过调研发现，现有的OLAP数据库执行引擎往往是在已有的OLTP执行引擎的基础之上，进行二次开发而来，存在性能损耗大、历史包袱重、未充分利用最新优化技术、未充分发挥新硬件优势等问题。 随着数据量的快速增长和数据分析需求的日趋强劲，OLAP系统所需要承担的计算量也呈指数级增长，现有系统的性能难以满足未来的在线数据分析的需求。经过分析，阿里巴巴OLAP团队认为，真正面向全面上云时代、面向数字经济时代的OLAP执行引擎，应当具备如下技术特点： • 支持多种硬件平台 。满足企业上云需求，支持多种硬件平台。除了支持传统X86平台，也应当兼容ARM平台，同时支持利用GPU、FPGA等新兴硬件进行加速。 • 极致性价比 。充分利用硬件性能，精选最佳算法和算子实现，提升硬件执行效率。对于密集、复杂的计算，使用特殊算法特殊硬件来提升效率。 • SQL 兼容性高 。高度兼容现有的SQL标准、优化器标准、存储标准，减少用户的迁移难度和学习难度。用户无需改写SQL，无需重新学习优化技术，无需迁移数据，仅需要进行小版本软件升级，即可享受到最新的性能优化技术。 为了解决如上需求

第二次随笔 周/N 新增代码 累计代码 本周耗时 累计耗时 重要成长 1 0 0 24 24 看文献，拓展视野 2 30 30 24 48 1、初始化认知用户SU信道信息 2、主用户不同量化比特数下的干扰上下行 3、信令链路节点反馈信息速率 4、学习迭代优化算法 难点 1、节点和主次用户之间的反馈机制和传输速率优化实现（...） 2、基本网络拓扑，节点、获取信道状态信息之间联系以及联合优化（准备采用博弈论思维解决） 3、通透基本概念，打下基础 4、切合主题能效，从功率优化入手 来源： https://www.cnblogs.com/weiyangxiong/p/12547166.html

　　在学习Java锁的时候，总觉的比较含糊，感觉一直没有系统的消化理解。所以决定重新梳理一下java相关的锁。 　 　 本质来说只有两种锁，乐观锁和悲观锁，其他所谓的可重入、自旋、偏向/轻量/重量锁等，都是锁具有的一些特点或机制。目的就是在数据安全的前提下，提高系统的性能。 乐观锁 　　 乐观锁，顾名思义，就是说在操作共享资源时，它总是抱着乐观的态度进行，它认为自己可以成功地完成操作。但实际上，当多个线程同时操作一个共享资源时，只有一个线程会成功，那么失败的线程呢？它们不会像悲观锁一样在操作系统中挂起，而仅仅是返回，并且系统允许失败的线程重试，也允许自动放弃退出操作。所以，乐观锁相比悲观锁来说，不会带来死锁、饥饿等活性故障问题，线程间的相互影响也远远比悲观锁要小。更为重要的是，乐观锁没有因竞争造成的系统开销，所以在性能上也是更胜一筹。 　　CAS 是实现乐观锁的核心算法，它包含了 3 个参数：V（需要更新的变量）、E（预期值）和 N（最新值）。只有当需要更新的变量等于预期值时，需要更新的变量才会被设置为最新值，如果更新值和预期值不同，则说明已经有其它线程更新了需要更新的变量，此时当前线程不做操作，返回 V 的真实值。 　　 如何实现原子操作 　　在 JDK 中的 concurrent 包中，atomic 路径下的类都是基于 CAS 实现的。AtomicInteger 就是基于

本博客是阅读<java time and space performance tips>这本小书后整理的读书笔记性质博客，增加了几个测试代码，代码可以在此下载： java时空间性能优化测试代码 ，文件StopWatch是一个秒表计时工具类，它的代码在文末。 1. 时间优化 1.1 标准代码优化 a. 将循环不变量的计算移出循环 我写了一个测试例子如下： import util.StopWatch; /** * 循环优化： * 除了本例中将循环不变量移出循环外，还有将忙循环放在外层 * @author jxqlovejava * */ public class LoopOptimization { public int size() { try { Thread.sleep(200); // 模拟耗时操作 } catch(InterruptedException ie) { } return 10; } public void slowLoop() { StopWatch sw = new StopWatch("slowLoop"); sw.start(); for(int i = 0; i < size(); i++); sw.end(); sw.printEclapseDetail(); } public void optimizeLoop() { StopWatch sw =

代码中如果if-else比较多，阅读起来比较困难，维护起来也比较困难，很容易出bug，接下来，本文将介绍优化if-else代码的八种方案。 优化方案一：提前return，去除不必要的else 如果if-else代码块包含return语句，可以考虑通过提前return，把多余else干掉，使代码更加优雅。 优化前 if(condition){ //doSomething }else{ return ; } 优化后 if（!condition）{ return ; } //doSomething 优化方案二：优化逻辑结构，让正常流程走主干 优化前 public double getAdjustedCapital(){ if(_capital <= 0.0 ){ return 0.0; } if(_intRate > 0 && _duration >0){ return (_income / _duration) *ADJ_FACTOR; } return 0.0; } 优化后 public double getAdjustedCapital(){ if(_capital <= 0.0 ){ return 0.0; } if(_intRate <= 0 || _duration <= 0){ return 0.0; } return (_income / _duration) *ADJ

一、浏览器的按键事件总结 用js实现键盘记录，要关注浏览器的三种按键事件类型，即keydown，keypress和keyup，它们分别对应onkeydown、 onkeypress和onkeyup这三个事件句柄。一个典型的按键会产生所有这三种事件，依次是keydown，keypress，然后是按键释放时候的keyup。 在这3种事件类型中，keydown和keyup比较底层，而keypress比较高级。这里所谓的高级是指，当用户按下shift + 1时，keypress是对这个按键事件进行解析后返回一个可打印的“!”字符，而keydown和keyup只是记录了shift + 1这个事件。但是keypress只能针对一些可以打印出来的字符有效，而对于功能按键，如F1-F12、Backspace、Enter、Escape、 PageUP、PageDown和箭头方向等，就不会产生keypress事件，但是可以产生keydown和keyup事件。然而在FireFox中，功能按键是可以产生keypress事件的。 传递给keydown、keypress和keyup事件句柄的事件对象有一些通用的属性。如果Alt、Ctrl或Shift和一个按键一起按下，这通过事件的altKey、ctrlKey和shiftKey属性表示，这些属性在FireFox和IE中是通用的。 二、兼容浏览器

目录 第一次作业 第二次作业 第三次作业 总结 体会 第一次作业 作业分析 本次作业任务： 简单多项式导函数的求解 。 经历第一单元的 摧残 洗礼之后，再来看第一次作业的要求确实很水。由于表达式中只存在幂函数且每一项遵循 a*x**b 的格式，同时也不用考虑 WRONG FORMAT! 的情况，我们的工作就显得十分轻松了。 去除多余的空白符，并且整理多余的加减号。 使用 正则 解析表达式，并且创建实例化对象。 根据求导规则进行求导。 优化求导之后得到的表达式，输出。 其中对于输出表达式的优化策略主要包括以下： 处理系数1、-1，处理指数0、1。 合并同类项。 根据系数大小排序，保证正数在前。 UML图 本次作业，为保证后续的迭代工作，建立了Item抽象类，并设立了求导抽象方法。但是由于对后续迭代的情况考虑不周，第二次作业还是选择了 重构 。 度量分析 Method ev(G) iv(G) V(G) Item.checkItem(Item,ArrayList ) 4 5 6 Item.fervation() 1 1 1 Item.getCoef() 1 1 1 Item.getIndex() 1 1 1 Item.getItem(String,ArrayList ) 1 1 1 Item.setCoef(BigInteger) 1 1 1 Item.setIndex

这段时间对项目做了一次整体的优化，全站有了20%左右的提升（本来载入速度已经1.2S左右了，优化度很低），算一算已经做了四轮的全站性能优化了，回顾几次的优化手段，基本上几个字就能说清楚： 传输层面：减少请求数，降低请求量 执行层面：减少重绘&回流 传输层面的从来都是优化的核心点，而这个层面的优化要对浏览器有一个基本的认识，比如： ① 网页自上而下的解析渲染，边解析边渲染，页面内CSS文件会阻塞渲染，异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源，新开线程下载（有并发上限），在带宽限制的条件下，无序并发会导致主资源速度下降，从而影响首屏渲染 ③ 浏览器缓存可用时会使用缓存资源，这个时候可以避免请求体的传输，对性能有极大提高 衡量性能的重要指标为首屏载入速度（指页面可以看见，不一定可交互），影响首屏的最大因素为请求，所以请求是页面真正的杀手，一般来说我们会做这些优化： 减少请求数 ① 合并样式、脚本文件 ② 合并背景图片 ③ CSS3图标、Icon Font 降低请求量 ① 开启GZip ② 优化静态资源，jQuery->Zepto、阉割IScroll、去除冗余代码 ③ 图片无损压缩 ④ 图片延迟加载 ⑤ 减少Cookie携带 很多时候，我们也会采用类似“时间换空间、空间换时间”的做法，比如： ① 缓存为王，对更新较缓慢的资源&接口做缓存（浏览器缓存

某厂面试归来，发现自己落伍了！>>> 转自： http://blog.csdn.net/lw1a2/archive/2006/12/10/1437402.aspx 编译 ， 编译程序读取源程序（字符流） ， 对 之进行词法和语法的分析 ， 将高级语言指令转换为功能等效的汇编代码，再由汇编程序转换为机器语言，并且按照操作系统对 可执行文件格式的要求链接生成可执行程序。 C源程序头文件－－>预编译处理(cpp)－－>编译程序本身 －－>优化程序－－>汇编程序－－>链接程序-->可执行文件 1.编译预处理 读取c 源程序，对其中的伪指令（以 # 开头的指令）和特殊符号进行处理 [析] 伪指令主要包括以下四个方面 （1） 宏定义指令，如 #define Name TokenString,#undef 等。对于前一个伪指令，预编译所要做的是将程序中的所有 Name 用 TokenString 替换，但作为字符串常量的 Name 则不被替换。对于后者，则将取 消对某个宏的定义，使以后该串的出现不再被替换。 （ 2 ）条件编译指令，如 #ifdef,#ifndef,#else,#elif,#endif, 等等。这些伪指令的引入使得程序员可以通过定义不同的宏来决定编译程序对哪些代码进行处理。预编译程序将根据有关的文件， 将那些不必要的代码过滤掉 （ 3 ）头文件包含指令，如 #include

重复优化的思考 这段时间对项目做了一次整体的优化，全站有了20%左右的提升（本来载入速度已经1.2S左右了，优化度很低），算一算已经做了四轮的全站性能优化了，回顾几次的优化手段，基本上几个字就能说清楚： 传输层面：减少请求数，降低请求量执行层面：减少重绘&回流 传输层面的从来都是优化的核心点，而这个层面的优化要对浏览器有一个基本的认识，比如： ① 网页自上而下的解析渲染，边解析边渲染，页面内CSS文件会阻塞渲染，异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源，新开线程下载（有并发上限），在带宽限制的条件下，无序并发会导致主资源速度下降，从而影响首屏渲染 ③ 浏览器缓存可用时会使用缓存资源，这个时候可以避免请求体的传输，对性能有极大提高 衡量性能的重要指标为首屏载入速度（指页面可以看见，不一定可交互），影响首屏的最大因素为请求，所以请求是页面真正的杀手，一般来说我们会做这些优化： 减少请求数 ① 合并样式、脚本文件 ② 合并背景图片 ③ CSS3图标、Icon Font 降低请求量 ① 开启GZip ② 优化静态资源，jQuery->Zepto、阉割IScroll、去除冗余代码 ③ 图片无损压缩 ④ 图片延迟加载 ⑤ 减少Cookie携带 很多时候，我们也会采用类似“时间换空间、空间换时间”的做法，比如： ① 缓存为王，对更新较缓慢的资源&接口做缓存