优化

任何网站，都不是纯粹的外在事物，而是有一些内在的权重和权威，这是整个网站的核心。在网站搜索引擎优化的过程中，文章的内容是非常重要的一部分。它确实提高了文章内容的权威性。这将对整个网站的优化发挥重要作用。 　　在SEO优化过程中，对整个优化过程来说，真正提高网站的内容是非常重要的，不仅要满足更多的用户需求，更要便于搜索。在网站优化的过程中，真正有更权威的文章，也会给整个网站带来更多的好处。我们必须做好这些方面的工作，并考虑到这些权威文章的作用。在优化网站的过程中，我们也应该在未来多加考虑。 　　在SEO优化过程中，为了真正提高内容的权威性，应该有一些权威的数据。在互联网时代的今天，不同的数据和各种资源可以搜索，和更权威的数据可以被添加到写文章，这样更多的人可以相信，自然可以提高文章的内容的权威，这是非常重要的搜索整个网站的关键。 　　网站文章的数据更权威，这一次被更多的人更容易地转载和传播，是转载的一篇文章，更多次的人，所以它可以增加网站的反向链接，搜索引擎优化优化有重要的工作，它必须认真完成这些方面想想，然后有一个更好的收获。认真做好这些方面的工作，不断增加权威，最终会带来更好的结果，优化网站也是至关重要的。 　　真正权威的文章是网站内容的保证。seo人员必须做的正确，做用户或访客真正关注的内容，然后可以使网站更好，忠实粉丝跟过。 　　SEO优化过程中，可以增加文章的内容的权威

球形高斯近似 之前提到， 这篇文章 介绍了通过 球形高斯近似 来优化 pow 的计算，代码如下： 优化前： // Generalized Power Function float pow(float x, float n) { return exp(log(x) * n); } 优化后： // Spherical Gaussian Power Function float pow(float x, float n) { n = n * 1.4427f + 1.4427f; // 1.4427f --> 1/ln(2) return exp2(x * n - n); } 推导 关于上面代码的推导，可以参考 这篇文章 ，这里再列一下主要推导过程： pow 的 球形高斯近似 : pow(nh, K) = exp(-K*(1-nh)) 其中 exp 可以用 exp2 这样表示： exp(a) = exp2(a/ln(2)) 带入后得到： pow(nh, K) = exp2(-(K/ln(2))(1-nh)) 这里的 1 / ln(2) 是一个常量，约等于 1.4427f ，我们可以提前计算好，再带入上面的公式： pow(nh, K) = exp2(-(K*1.4427f)(1-nh)) = exp2(nh*K*1.4427f-K*1.4427f) 把 K*1.4427 提出来后可以得到：

直播无疑是 2016 年的大热话题，七牛云在 6 月底发布了实时流网络 LiveNet 和直播云解决方案后，我们用《直播技术详解》系列文章系统地介绍了直播各个环节的关键技术，帮助视频直播创业者们更全面、深入地了解直播技术，更好地技术选型。 《直播 SDK 性能优化实践》系列文章是介绍七牛云在直播 SDK 上的技术创新实践。欢迎探讨。 弱网优化的场景 网络直播行业经过一年多的快速发展，衍生出了各种各样的玩法。最早的网络直播是主播坐在 PC 前，安装好专业的直播设备（如摄像头和麦克风），然后才能开始直播。后来随着手机性能的提升和直播技术的进步，主播只需要有手机和有网络就可以直播。直播发展到现在，单一的室内聊天互动直播已经无法满足观众的需求。主播们开始走向户外，在更多的场景下直播。 在可以预见的未来，这种直播形式会快速发展。直播的内容会更优质，直播的形式也会从单纯的娱乐转向体验。 直播想延伸到户外需要克服很多困难，而最主要的困难就是应对不稳定的网络。移动网络下，通常容易遇到网络不稳定，连接被重置，断线重连，一方面频繁重连，建立连接需要开销。另一方面尤其是发生 GPRS/2G/3G/4G 切换时，带宽可能出现瓶颈。当带宽不够，帧率较高/码率较高的内容较难发送出去，这个时候就需要我们在不同网络状况执行不同的策略编码推流，让观众可以看到最优质的直播视频。 直播无疑是 2016 年的大热话题

一篇伯乐在线的综述性（且自带相关链接）的文章 Web前端优化最佳实践及工具集锦 ###Google 原汁： https://developers.google.com/web/fundamentals/ 伯乐在线翻译： http://blog.jobbole.com/45574/ ###Yahoo 原汁： https://developer.yahoo.com/performance/ 中文： Fenng博客 erichan博客 来源： oschina 链接： https://my.oschina.net/u/2248036/blog/619639

VIM默认使用的过程中有一个重要的问题，就是打开多个文件的时候无法可视化看到打开的文件，并在这些文件中切换。MiniBufExplorer是一个常用的buffer切换插件，但是这个插件在Windows下使用的时候有许多问题，同时也太繁琐。buf_it [1] 则实现了轻量的buffer管理，但是buf_it同样在windows下有许多问题，而buf_it的退出机制也会出现只想关闭一个文件确关闭了整个vim的情况。 基于这两个问题，我修改了buf_it插件，这里共享出来，欢迎大家提意见。先给张图 修改： 1 windows下使用GVIM优化，方式多开一个空白缓冲区，windows下gvim右键配置见参考文献2 2 增加自定义退出方式 3 修改了部分快捷键，只是个人习惯，可无视之 安装： 直接扔到plugin目录就行，原作者没写doc，那我也不写啦。 配置： nnoremap <Leader>wq :w<CR><Esc>:call BufClose()<CR> nnoremap <Leader>q :call BufClose()<CR> nnoremap <Leader>w :w<CR> nnoremap <Leader>x :bd!<CR><Esc>:call BufClose()<CR> 使用： shift+h,l ：左右切换tab <leader>be ：BufEcho

温馨提示：本篇内容均来自网上，本人只做了稍微处理，未进行细致研究，仅当做以后不备之需，如若你喜欢可尽情转走。 性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化。为了获得稳定的执行性能，SQL语句越简单越好。对复杂的SQL语句，要设法对之进行简化。 常见的简化规则如下： 1）不要有超过5个以上的表连接（JOIN） 2）考虑使用临时表或表变量存放中间结果 3）少用子查询 4）视图嵌套不要过深,一般视图嵌套不要超过2个为宜 连接的表越多，其编译的时间和连接的开销也越大，性能越不好控制。最好是把连接拆开成较小的几个部分逐个顺序执行。优先执行那些能够大量减少结果的连接。拆分的好处不仅仅是减少SQL Server优化的时间，更使得SQL语句能够以你可以预测的方式和顺序执行。如果一定需要连接很多表才能得到数据，那么很可能意味着设计上的缺陷。 连接是outer join，非常不好。因为outer join意味着必须对左表或右表查询所有行。如果表很大而没有相应的where语句，那么outer join很容易导致table scan或index scan。要尽量使用inner join避免scan整个表。 优化建议： 1）使用临时表存放t1表的结果,能大大减少logical reads（或返回行数）的操作要优先执行

一、 文件大小： ps文件大小：200 —300 MB/个； 二、 ps优化： 1、 Photoshop 安装32位（64位占用资源多）； 2、 内存使用情况 ： Photoshop是64位的本机应用程序，因此你为它提供多大的内存，它都可以使用的完。在处理较大尺寸的图像时，更多的内存将会更有利。默认情况下，Photoshop将会分配70%的内存让其使用，但是你可以通过菜单 编辑 > 首选项 > 性能 来改变这个数值。数值改变之后，重启Photoshop才会生效。这可能是提升Photoshop性能最有效的方式。 3、 使用暂存盘 ： 当你的内存完全使用时，电脑的硬盘将会承载剩余的工作量。默认情况下，你的暂存盘为系统(启动)分区，通常系统分区已经负载了你的安装应用程序和操作系统。建议你增加所有空闲的硬盘作为暂存盘，在菜单 编辑 > 首选项 > 性能 下可打开暂存盘选项窗口，并且点击右方的上下箭头根据硬盘的使用情况进行优先级排序。 你可以在Photoshop的性能设置窗口分配并且进行优先排序。 4、 效率指示器 ：（ 重构同学可以忽略） 如果你在文档窗口的下方状态栏选择了效率，你可以看到Photoshop的效率级别。如果显示100%，意味着效率最高。你可以通过减少图层和智能对象的数量来提升效率，不过由于未保留可编辑的源图层，这样可能会破坏你的工作流程。 5、 高速缓存与历史记录 ：

元旦前后，网站增加了直播功能，但发现，有时候打开页面，网站反应很慢。 吓死宝宝了，以为服务器出了啥子问题。 后来发现，由于上传图片，当一个页面有十多张图片，每个图片都有一兆多的时候，瞬间占满了一兆的带宽。 问题来了，就得解决。 原来的服务器文件，上传了，就放在那里，请求来了，便给。这样，如果一个页面有三两个一兆以上的文件，便会加载很慢，同时，其他访问，便拥堵了。 还有一个问题，原来的文件，都放到了数据库里，这样方便服务器横向扩展的时候，不用关心文件，反正都在数据库里。但，租用的数据库，也渐渐地满了。 最快捷的解决方法：加钱买啊！ 钱能解决的问题，就不是问题。可，问题是没钱。 且，这么简单粗暴地解决问题，也不是我得风格。 于是，挽起袖子，自己解决。 需求如下： 1.图片要处理。图片有多种使用场景，缩略图，常规图，广告图片，海报图片等，规格都不一样。要随需供应。 2.语音也要处理。目前找到的文件500KB左右，加载要三两秒时间，明显等待。不爽。 3.要缓存。 4.支持所有文件。一个是用户上传的文件，另一个是ckeditor插件上传和管理的文件。 功能实现。 这是有史以来最废纸的功能，用了两页纸！平日里，一个功能，半张一张的，也就够了。 FreeFile领域类，用于存储文件元数据。主要是名称大小，路径之类（不再存数据库了）。为啥叫FreeFile，没啥意思，我是个爱自由的人。也想

本文以SmartPro 6000F使用的nios ii内核为例，详述了如何搞定cache，将程序的运行时间从最开始的30s优化到25s，再从25s优化到最终的24s。尤其是那最后1s的优化，遇到了很多问题，而这些问题在嵌入式系统里，任何一款配置了cache的处理器都可能会碰到，所以特撰此文献给那些还在倍受cache折磨的工程师们。全文分上下两部，上部为如何搞定指令cache，下部为如何搞定数据cache。 SmartPro 6000F使用全FPGA架构，并内嵌了4颗nios II软核，我们使用的开发环境是nios for eclipse，编译器是gcc。在帮客户定制一款nandflash编程时序时，为了进一步提高编程速度，准备对时序进行优化。默认情况下，gcc的优化等级为最低的O0，编程时间为30s，开启O1一级优化后，编程时间降到了25s，当开启O2二级优化后，编程时间没有继续下降，反而又上升到了29s。 虽然不同优化等级之间时间差别就不到5s，我们完全可以很省事的开启O1级别优化时序，然后就交付给客户，但是当时我们并没有这么做。因为理论上，优化等级越高，编程时间应该越少才对，但是现在测试的编程时间结果是 O0 > O2 > O1，冥冥中感觉时序还可以再优化些，速度还可再快一点。 目前提速遇到的问题是：使用更高的优化等级，编程时间反而更多了，这可不符合gcc的优化规律阿

这里的优化方面只在sql【spark】层面，对于参数的调整，这里不做介绍。 1、表设计层面优化 ① 尽量使用分区表操作。 ② 利用桶表优化 ③ 选择合适的文件存储格式 2、语法和参数层面 ① 优先过滤数据 尽量减少每个阶段的数据量，对于分区表能用上分区字段的尽量使用，同时只选择后面需要使用到的列，最大限度的减少参与join的数据量。 除了需要必须表里所有的字段，否则禁止使用select * ② 小表join大表原则 小表join大表的时候应遵守小表join大表原则，原因是join操作的reduce阶段，位于join左边的表内容会被优先加载进内存，将条目少的表放在左边，可以有效减少发生内存溢出的几率，join中执行顺序是从左到右生成job，应该保证连续插叙中的表的大小从做到右依次增加。 ③尽量原则操作 尽量避免一个sql包含复杂的逻辑，可以使用中间表来完成复杂的逻辑。 ④ order by 优化 order by只能在一个reduce进程中进行，所以如果对一个大数据集进行order by，会导致一个reduce进程中处理的数据相当大，造成查询执行缓慢。 推荐：在最终结果上进行 order by ，不要在中间的大数据集上进行排序。如果最终结 果较少，可以在一个reduce上进行排序时，那么就在最后的结果集上进行 order by。 如果是去排序后的前N条数据，可以使用