优化

编程珠玑

独自空忆成欢 提交于 2019-12-07 01:41:01
到了第六步,我们只是理论上探讨优化的步骤,最后,我们进行集体测试,使用敏感词越多,效果越明显: package test; import static util.PrintUtil.print; import java.io.BufferedReader; import java.io.FileReader; import java.io.IOException; import java.util.ArrayList; import java.util.Arrays; import java.util.HashMap; import java.util.Iterator; import java.util.Map; import java.util.Map.Entry; public class Test { static int key_max = 0; // 敏感词最大长度 static String[] keys = {"办证", "气枪出售", "裸聊", "裸表演", "土枪卖"}; static String tContent = "再办证顶"; static ArrayList<String> first = new ArrayList<String>(); static String[] sortFirst; static char[] charFirst;

读《代码重构》一书小计

淺唱寂寞╮ 提交于 2019-12-06 19:38:07
通过阅读《代码重构》一书,让我了解的最重要的一点是“重构不同于优化”。在这之前,我的观念中,“重构”与“优化”是划等号的。不过通过这本书,我了解到他们做着完全不同的事情,甚至是对立的。 下面讲讲重构一书中对我当前有用的部分: 第一章: 重构原则:去除临时变量 需要注释的地方都可以提取函数或方法(用函数名作为注释) 函数或方法名应该描述实现什么功能,而不是描述怎么实现 对比:重构——使代码(对人)易读、易改、易复用 优化——提高代码性能(往往使代码难以理解) 开发正常流程:增加新功能-》重构-》增加新功能-》重构……(一个正常的开发者,往往在这之间不断来回切换,间隔有时只有几分钟。要时刻知道自己当前是在增加新功能还是在重构) 第二章: 重构作用: 重构改进软件设计——去除重复代码(代码维护变得简单) 重构使软件更易理解 重构帮助寻找bug(随着理解的加深,bug浮出水面) 重构提高编程速度(短期拖慢进度,提高的是后续的编程速度,达到整体的进度加快、速度提高。如果一个项目接近尾声,就不要使用重构,因为重构只会起到反作用) 第三章: 自动测试: 一个开发人员,开发过程中,70%以上的时间是在做测试工作。这足以体现自动测试的重要性。 之后的8章讲的是在重构工具中使用的各种函数,对我来说是没有任何用处的,所以就没有看。 来源: oschina 链接: https://my.oschina

悠然乱弹:一段SQL引发的性能危机及其背后隐藏的设计缺陷

倾然丶 夕夏残阳落幕 提交于 2019-12-06 19:37:55
有个同学,说是系统中出现性能问题了,说是让我帮助诊断一下。本来是不想花这时间的,结果耐不住对方的死缠乱打,只要答应帮看看。 故事发生的背景是,在文件上传的时候,有时间会有人上传了文件,但是最后没有使用上传的文件,这样就会产生一些垃圾文件。 原来软件作者就想写一个后台定时任务程序,来清除这些垃圾文件? 由于作者坚定的不让我发她的SQL语句(这个我也理解,这么丑陋的SQL),所以这里就不发源代码了,发伪代码。 void deleteMissLinkFile{ List fileList=getFileList(); List deleteFileList=new ArrayList(); for(file:fileList){ int count1=execute(select count(*) from ...); int count2=execute(select count(*) from ...); int count3=execute(select count(*) from ...); int count4=execute(select count(*) from ...); int count5=execute(select count(*) from ...); if(count1==0&&count2==0&&count3==0&&count4==0&&count5=

beta版本——第一次冲刺

拈花ヽ惹草 提交于 2019-12-06 11:56:34
第一次冲刺 (1)SCRUM部分☁️ ✨成员描述: 姓名 李星晨 完成了哪个任务 增加了个人中心返回主页按钮 花了多少时间 1h 还剩余多少时间 1h 遇到什么困难 没有遇到问题 这两天解决的进度 1/2 后续两天的计划 继续进行界面的优化 ⏳ 姓名 唐财伟 完成了哪个任务 压缩了影响页面加载速度的静态资源 花了多少时间 2h 还剩余多少时间 0h 遇到什么困难 对于图片等资源,需要权衡压缩程度 这两天解决的进度 已完成 后续两天的计划 无 ⏳ 姓名 陈嘉莹 完成了哪个任务 认证学校那一栏增加检测机制 花了多少时间 2h 还剩余多少时间 2h 遇到什么困难 认证部分之前是另一个同学写的,重新屡一遍他的代码并找到bug的位置比较麻烦。 这两天解决的进度 解决了认证之后数据回显到页面的问题,以及点击认证按钮后出现的各种错误。 后续两天的计划 解决用户不可重复认证的问题,及进行基本的测试。 ⏳ 姓名 谭伟 完成了哪个任务 解决用户对同个订单多次提交评分的bug 花了多少时间 3小时 还剩余多少时间 0 遇到什么困难 后端在进行查询时笨比,导致一直无法对订单进行评分 这两天解决的进度 已完成 后续两天的计划 无 ⏳ 姓名 刘伊凡 完成了哪个任务 对个人中心优化的测试 花了多少时间 0.5h 还剩余多少时间 1.5h 遇到什么困难 没有遇到问题 这两天解决的进度 完成 后续两天的计划

ORM优化查询、choices参数

不羁的心 提交于 2019-12-06 06:47:10
目录 ORM查询优化 only与defer select_related和prefetch_related MTV与MVC模型 choices参数 ORM查询优化 only与defer res = models.Book.objects.all() 这样是不会有任何返回结果,因为ORM是惰性查询,减少不必要的数据库操作,降低数据库的压力。 也就是说 能少走一次数据库就少走一次 ,最好是一次数据库都不要走或者说之走一次。 only优化: res = models.Book.objects.only('title') # 括号内查询的字段可以有多个 print(res) # 查询一次,打印一条sql查询语句 for i in res: print(i.title) # 查询一次,打印一条sql查询语句 print(i.price) # 有几个对象,就查询几次,打印几条sql查询语句 only会把括号内字段对应的值,封装到查询返回的对象中,通过对象点括号字段, 不需要再走数据库查询,直接返回结果 , 一旦你点了不是括号内的字段 就会频繁的去走数据库查询 defer优化 res = models.Book.objects.defer('title') # print(res) for i in res: # print(i.title) print(i.title) 和 only相反

悠然乱弹:从几个方法的重构讲开去--性能大优化

怎甘沉沦 提交于 2019-12-06 02:59:58
上一篇 讲到经过上面两篇的优化与重构,整体来说,前面提到的问题,除了性能问题之外,其它问题都已经顺利的解决了。 现在还存在多次扫描处理的问题,也就是说虽然代码结构性重构是成功的,但是性能问题还是没有根本解决。 在给出解决方案之前,需要对这个处理方式缕一缕: 处理方式1:每次遍历全路径找到待处理文件,文件然后批量进行处理。优点是处理起来比较简单,但是会重复扫描。 处理方式2:一次遍历所有文件,然后对每个文件进行注解检测。扫描全路径只有一次,然后要把每个文件与过滤器进行比较如果比较成功那就做,比较不成功就不做。 稍加分析就会发现,两种方式的比较次数是一样的,但是第二种方案遍历文件的次数就少到极限了,还能比1次更少么?? 这次的做法就有点复杂了(相对的,实际上也很简单),做一个过滤器,里面放个Map存储过滤器:处理器。 对于每个一个文件,都对所有的过滤器进行校验,如果校验成功,就执行对应的处理器。 public class ComplexFileFilter implements FileObjectFilter { Map<FileObjectFilter,FileObjectProcessor> filterProcessorMap; public boolean accept(FileObject fileObject) { for(FileObjectFilter filter

Nginx 作为反向Proxy 的优化要点

左心房为你撑大大i 提交于 2019-12-06 01:06:08
常用优化要点 当nginx用于反向代理时,每个客户端将使用两个连接: 一个用于响应客户端的请求,另一个用于到后端的访问; 如果机器是两核CPU,例如: $ grep ^proces /proc/cpuinfo | wc -l 2 那么,可以从如下配置起步: # One worker per CPU-core. worker_processes 2; events { worker_connections 8096; multi_accept on; use epoll; } worker_rlimit_nofile 40000; http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 15; } 标准的代理配置 下面是一个基本的反向代理配置模板,将所有请求都转发给指定的后端应用。 例如,到 http://your.ip:80/ 的请求都将重定向到 http://127.0.0.1:4433/ 私有服务器 : # One process for each CPU-Core worker_processes 2; # Event handler. events { worker_connections 8096; multi_accept on; use epoll; } http { # Basic

正确创建本地C++发布构建PDBS

自作多情 提交于 2019-12-05 23:54:06
在调试版本中遇到的一个问题是编译本地的C++应用程序。例如,许多局部变量消失了,因为代码生成器没有将它们放在堆栈上,而是将它们放在寄存器中,就像在调试生成中发生的那样。此外,release积极地构建对函数的内联调用,因此代码生成器将函数体直接放入调用方法中。一旦您习惯了编译器的模式,并了解了一点汇编语言,就不难理解在调试发行版生成代码时会发生什么。 我想在本文中介绍的是在不加应用程序的情况下正确创建本地C++发布PDB所必需的精确开关,这样我就可以回答隐形的问题了。我将向您展示的开关与优化无关,PDB文件的创建不会影响优化。 要设置的第一个开关是在编译器CL.EXE上,它是/Zi。此开关将调试信息放入.OBJ文件中,以便链接器将其放入最终PDB。您将在项目的C/C++属性页中设置这个开关。如下图 接下来的三个开关应用于链接器LINK.EXE。第一个命令/DEBUG告诉链接器您要为该生成创建PDB文件。如下: /DEBUG开关有个小问题。打开它会告诉链接器您正在执行未优化的生成,所以/DEBUG隐式地打开/INCREMENTAL并实质上创建一个调试生成,尽管编译器优化会应用(但不是链接时代码生成优化)。这对您意味着链接器以“快速模式”链接,因此如果您的OBJ中有300个函数,但您只引用(即,使用)其中一个函数,那么链接器会将所有300个函数放入输出二进制文件中。是的

【整理】Nginx 战斗准备 —— 优化指南

旧街凉风 提交于 2019-12-05 22:58:45
本文内容参考自《 Nginx 战斗准备 —— 优化指南 》。 【一句话总结】 本文不是一个全面的微调指南,而是让你了解哪些设置能够让你在大量客户端访问时拥有良好的性能,为什么它们会提高性能。 【知识点】 worker_processes 定义了 nginx 对外提供 web 服务时的 worder 进程数。 worker_rlimit_nofile 更改 worker 进程的最大打开文件数限制。 events 模块 中包含 nginx 中所有和处理连接相关的设置。 worker_connections 的值和 worker_rlimit_nofile 值有关系,该值的大小同时受限于系统可以使用的端口数目(~64k)。 multi_accept 告诉 nginx 在收到关于新连接的可读通知后,应尽可能处理掉当前存在的所有来自客户端的连接。 use 设置用于采用哪种 I/O 复用方式。 http 模块 控制着 nginx http 处理的所有核心特性。 server_tokens 并不会让 nginx 执行的速度更快,但它可以关闭在错误页面中的 nginx 版本数字,这样对于安全性是有好处的。 sendfile 使能 sendfile() 的使用,在内核态完成相关动作,更高效。 tcp_nopush 告诉 nginx 在一个数据包里发送所有 HTTP 包头,而不是通过 TCP 的

揭秘 TiDB 新优化器:Cascades Planner 原理解析

不羁岁月 提交于 2019-12-05 22:22:52
作者:MingCong Han 在《 十分钟成为 Contributor 系列 | 为 Cascades Planner 添加优化规则 》中,我们简单介绍了 Cascades 的相关背景知识,本文将为大家深入介绍 TiDB 新的优化器——Cascades Planner 的框架及原理。 TiDB 当前优化器简介 关系型数据库中查询优化器的作用是为一个 SQL 在合理的开销内产生一个合适的查询计划, TiDB 源码阅读系列文章(六)Select 语句概览 中介绍过 TiDB 当前优化器的基本组成,TiDB 当前的优化器将优化过程主要分为逻辑优化(Logical Optimize)和物理优化(Physical Optimize)两个阶段。逻辑优化是将一棵逻辑算子树(LogicalPlan Tree)进行逻辑等价的变化,最后的结果是一棵更优的逻辑算子树;而物理优化则是将一棵逻辑算子树转换成一棵物理算子树(PhysicalPlan Tree)。这棵物理算子树就是我们说的物理执行计划,将交由 TiDB 执行引擎去完成后续的 SQL 执行过程。 逻辑优化 TiDB 中,一个 SQL 在进入到逻辑优化阶段之前,它的 AST(抽象语法树)已经转换成了对应的逻辑算子树,因此逻辑优化就是将一个逻辑算子树进行逻辑上等价变换的过程。逻辑优化是基于规则的优化(Rule-Based Optimization