代码优化

查询速度慢的原因很多，常见如下几种： 1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) 2、I/O吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量） 7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷) 8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列 10、查询语句不好，没有优化 ●可以通过如下方法来优化查询 : 1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要. 2、纵向、横向分割表，减少表的尺寸(sp_spaceuse) 3、升级硬件 4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段 5、提高网速; 6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行 Microsoft SQL Server?

进入用友后，第一次的代码 优化前： 优化后： 优化前： 优化后： /** * 复制盘点计划 * @param planid * @return * @author xinqq * @create 2019-12-06 17:00 */ public Plan copyPlan ( String planid ) { if ( StringUtils . isBlank ( planid ) ) throwBusinessException ( I18nEnum . COMMON4 ) ; Plan oldPlan = queryService . queryPlanById ( planid ) ; Plan copyPlan = new Plan ( ) ; BeanUtils . copyProperties ( oldPlan , copyPlan , "id" , "name" , "version" , "state" , "creatorname" , "archivetime" ) ; copyPlan . setName ( oldPlan . getName ( ) + Toolkit . dateToStr ( new Date ( ) , "yyyyMMddhhmmss" ) ) ; copyPlan . setState ( OtrConstant .

Go 程序是怎样跑起来的 原创： 饶全成 码农桃花源 刚开始写这篇文章的时候，目标非常大，想要探索 Go 程序的一生：编码、编译、汇编、链接、运行、退出。它的每一步具体如何进行，力图弄清 Go 程序的这一生。 在这个过程中，我又复习了一遍《程序员的自我修养》。这是一本讲编译、链接的书，非常详细，值得一看！数年前，我第一次看到这本书的书名，就非常喜欢。因为它模仿了周星驰喜剧之王里出现的一本书 ——《演员的自我修养》。心向往之！ 在开始本文之前，先推荐一位头条大佬的博客——《面向信仰编程》，他的 Go 编译系列文章，非常有深度，直接深入编译器源代码，我是看了很多遍了。博客链接可以从参考资料里获取。 理想很大，实现的难度也是非常大。为了避免砸了“深度解密”这个牌子，这次起了个更温和的名字，嘿嘿。 下面是文章的目录： 引入 我们从一个 HelloWorld 的例子开始： package main import "fmt" func main() { fmt. Println ( "hello world" ) } 当我用我那价值 1800 元的 cherry 键盘潇洒地敲完上面的 hello world 代码时，保存在硬盘上的 hello.go 文件就是一个字节序列了，每个字节代表一个字符。 用 vim 打开 hello.go 文件，在命令行模式下，输入命令： :%!xxd 就能在 vim

前言 这几天，第三轮全站优化结束，测试项目在2G首屏载入速度取得了一些优化成绩，对比下来有10s左右的差距： 这次优化工作结束后，已经是第三次大规模折腾公司框架了，这里将一些自己知道的移动端的建议提出来分享下，希望对各位有用 文中有误请您提出，以免误人自误 技术选型 单页or多页 spa（single page application）也就是我们常常说的web应用程序webapp，被认为是业内的发展趋势，主要有两个优点： ① 用户体验好 ② 可以更好的降低服务器压力 但是单页有几个致命的缺点： ① SEO支持不好，往往需要单独写程序处理SEO问题 ② webapp本身的内存管理难，Javascript、Css非常容易互相影响 当然，这里不是说多页便不能有好的用户体验，不能降低服务器压力；多页也会有变量污染的问题发生，但造成webapp依旧是“发展趋势”，而没有大规模应用的主要原因是： webapp模式门槛较高，很容易玩坏 其实webapp的最大问题与上述几点没有关系，实际上阻碍webapp的是技术门槛与手机性能，硬件方面不必多说，这里主要说技术门槛。 webapp做的好，可以玩动画，可以玩真正意义上的预加载，可以玩无缝页面切换，从某些方面甚至可以媲美原生APP，这也是webapp受到追捧的原因。 但是，以上很容易被玩坏！因为webapp模式不可避免的需要用到框架

优化 PHP 代码技巧 1. 如果一个方法能被静态，那就声明他为静态的，速度可提高 1/4; 2. echo 的效率高于 print,因为 echo 没有返回值，print 返回一个整型; 3. 在循环之前设置循环的最大次数，而非在在循环中; 4. 销毁变量去释放内存，特别是大的数组; 5. 避免使用像__get, __set, __autoload 等魔术方法; 6. requiere_once()比较耗资源; 7. 在 includes 和 requires 中使用绝对路径，这样在分析路径花的时间更少; 8. 如果你需要得 sexinsex 到脚本执行时的时间，$_SERVER['REQUSET_TIME']优于 time(); 9. 能使用字符处理函数的，尽量用他们，因为效率高于正则;// 10. str_replace 字符替换比正则替换 preg_replace 快，但 strtr 比 str_replace 又快 1/4; 11. 如果一个函数既能接受数组又能接受简单字符做为参数，例如字符替换，并且参数列表 不是太长，可以考虑多用一些简洁的替换语句，一次只替换一个字符，而不是接受数组 做为查找和替换参数。大事化小，1+1>2; 12. 用@掩盖错误会降低脚本运行速度; 13. $row['id']比$row[id]速度快 7 倍，建议养成数组键加引号的习惯; 14.

1 简介 本章包含的话题有启动时间的测量、分析、人因工程（human factors）、初始化技术和优化技巧等。 产品花在启动方面的时间直接影响终端用户对该产品的第一印象。 一个消费电子设备不管如何引人注目或者设计得怎么好，设备从关机状态到可交互的使用状态所需的时间对于获得正面的用户体验尤为关键。案例 #1 就是在关机状态从头启动一个设备的例子。 启动一个设备涉及到许多步骤和一系列的事件。为了使用前后一致的术语，消费电子 Linux 论坛（CE Linux Forum）的启动时间优化工作组起草了一个术语词汇表，该表包括了相关术语在该领域内通用的定义。该词汇表如下： 启动时间相关的词汇表 2 技术/项目主页 下面主要介绍与减少 Linux 启动时间有关的各种技术。 有一部分描述了 eLinux.org 上可以下载的本地补丁，而其余部分则介绍了在其他地方维护的项目或者补丁。 2.1 测量启动时间 Printk Times – 用于显示每个 printk 的执行时间 内核函数跟踪（Ftrace） – 用于报告内核中每个函数的调用时间 Linux 跟踪工具箱（LTT） – 用于报告确切的内核和进程事件的时间数据 Oprofile（译注：最新替代品是 perf） – 通用的 Linux 分析器（Profile） Bootchart – 用于 Linux 启动过程的性能分析和数据展示

文章创作于 2019-11-08，2019-12-20 迁移至此。 作者有话说 “V8 是怎么跑起来的” 系列是我学习 V8 过程中的总结。从一年前正式成为前端工程师开始，我便有意识地了解和学习 V8。我也发现，在技术社区中鲜有内容新鲜的、原创度高的中文资料，于是开始将我学习过程中的总结分享出来。 由于工作繁忙，我已经半年没有更新博客。这个系列的引子是 4 月写的一篇 《V8 是怎么跑起来的 —— V8 中的对象表示》 ，我们通过使用 Chrome DevTools 验证的方式介绍了 V8 中的对象表示。 本文是这个系列真正意义的第一篇文章。文章的定位是这个系列的大纲，将按照 JavaScript 在 V8 中的执行流程，顺序介绍每一步的操作，并澄清一个社区中流传甚广的 “错误”。本文不会过于深究其中的细节（后续篇章将展开），您可以在评论中留下您想了解 V8 引擎的部分，也许下一篇选题会采纳并优先介绍。 祝阅读愉快。 1. 为什么是 V8 Any application that can be written in JavaScript, will eventually be written in JavaScript. 相信很多的朋友都听过前端界的一个著名定律，叫做 Atwood’s Law 。2007 年，Jeff Atwood 提出 “所有可以用 JavaScript

一.GitHub地址 https://github.com/RicardoDZX/wcPro 二.PSP表格 PSP2.1 PSP 阶段 预估耗时 （分钟） 实际耗时 （分钟） Planning 计划 30 20 · Estimate · 估计这个任务需要多少时间 30 20 Development 开发 470 550 · Analysis · 需求分析 (包括学习新技术) 30 20 · Design Spec · 生成设计文档 20 20 · Design Review · 设计复审 (和同事审核设计文档) 30 20 · Coding Standard · 代码规范 (为目前的开发制定合适的规范) 30 30 · Design · 具体设计 30 40 · Coding · 具体编码 180 240 · Code Review · 代码复审 30 30 · Test · 测试（自我测试，修改代码，提交修改） 120 150 Reporting 报告 90 90 · Test Report · 测试报告 30 30 · Size Measurement · 计算工作量 30 30 · Postmortem & Process Improvement Plan · 事后总结, 并提出过程改进计划 30 30 合计 590 660 三.模块编写/接口测试 我负责了输出控制模块

原文链接： https://www.520mwx.com/view/36709 一、中间表达形式（IR） 在编译原理课程中，我们通常将编译器分为前端和后端。其中，前端会对所输入的程序进行词法分析、语法分析、语义分析，然后生成中间表达形式，也就是 IR（Intermediate Representation ）。后端会对 IR 进行优化，然后生成目标代码。 如果不考虑解释执行的话，从 Java 源代码到最终的机器码实际上经过了两轮编译：Java 编译器将 Java 源代码编译成 Java 字节码，而即时编译器则将 Java 字节码编译成机器码。 对于即时编译器来说，所输入的 Java 字节码剥离了很多高级的 Java 语法，而且其采用的基于栈的计算模型非常容易建模。因此，即时编译器并不需要重新进行词法分析、语法分析以及语义分析，而是直接将 Java 字节码作为一种 IR。 不过，Java 字节码本身并不适合直接作为可供优化的 IR。这是因为现代编译器一般采用静态单赋值（Static Single Assignment，SSA）IR。这种 IR 的特点是每个变量只能被赋值一次，而且只有当变量被赋值之后才能使用。 y = 1; y = 2; x = y; 举个例子（ 来源 ），上面这段代码所对应的 SSA 形式伪代码是下面这段： y1 = 1; y2 = 2; x1 = y2;

1、引言 岁月真是个养猪场，这几年，人胖了，微信代码也翻了。 记得 14 年转岗来微信时，用自己笔记本编译微信工程才十来分钟。如今用公司配的 17 年款 27-inch iMac 编译要接近半小时；偶然间更新完代码，又莫名其妙需要全新编译。在这么低的编译效率下，开发心情受到严重影响。 于是年初我向上头请示，优化微信编译效率，上头也同意了。 学习交流： - 即时通讯/推送技术开发交流5群： 215477170 [推荐] - 移动端IM开发入门文章：《 新手入门一篇就够：从零开发移动端IM 》 （本文同步发布于： http://www.52im.net/thread-2873-1-1.html ） 2、相关文章 《 微信团队分享：微信移动端的全文检索多音字问题解决方案 》 《 微信团队分享：iOS版微信的高性能通用key-value组件技术实践 》 《 微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？ 》 《 微信团队原创分享：iOS版微信的内存监控系统技术实践 》 《 iOS后台唤醒实战：微信收款到账语音提醒技术总结 》 《 微信团队分享：微信Android版小视频编码填过的那些坑 》 《 微信手机端的本地数据全文检索优化之路 》 《 微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉 》 《 微信客户端团队负责人技术访谈