分析：此题不难，但特别容易超时！——这正是困难之处：有n个元素的集合的子集共有2^n个，枚举算法的时间复杂度在O(2^n)，且本题除枚举外别无他法（NP完全），因此必须尽一切可能性优化，着力在降低计算中n的值（以下1、2项优化）。关键的优化有以下几点（按重要性排列）：
继续阅读 »
tbox的默认内存分配，是完全基于自己的内存池架构，支持内存的快速分配，和对碎片的优化，并且支持各种内存泄露、溢出检测。
如果不想用tbox内置的默认内存分配管理，也可以灵活切换到其他分配模式，因为tbox现在已经完全支持allocator架构，
只要在init阶段传入不同的分配器模型，就能快速切换分配模式，例如：
```c
/* 采用默认的tbox内存管理，启用内存池维护、碎片优化、内存泄露溢出检测等所有特性
* 相当于使用了：tb_default_allocator(tb_null, 0)
*/
tb_init(tb_null, tb_null);
/* 采用默认的tbox内存管理，启用
继续阅读 »
前言
excerpt
paxos可以看做是2次 [多数派读写] 完成一次强一致读写. 多数派要求半数以上的参与者(paxos中的Acceptor)接受某笔操作. 但 [多数派读写] 并不一定需要多于半数的参与者, 分布式系统中某些场合的优化, 可以通过减少参与者数量来完成的.
本文介绍这些优化对系统可用性产生的影响, 根据什么标准来选择和调整这些参数.
继续阅读 »
整理/robin
本站推广
币安是全球领先的数字货币交易平台，提供比特币、以太坊、BNB 以及 USDT 交易。
币安注册: https://accounts.binancezh.pro/cn/register/?ref=11190872
邀请码: 11190872
【了解作者】
白鳝，真名徐戟，国内资深的系统优化专家。著有《Oracle优化日记》、《OracleRAC日记》。本文摘自《DBA日志》。
【DBA常用软件】
DBA 的电脑上需要安装什么软件？经常有人问老白，其实每个 DBA 都有自己喜欢使用的软件。对于使用什么软件，用的习惯，用的熟练就好。因为工具只是起到一个辅助的作用，工具的作用是帮助 DBA 思考，在
继续阅读 »
content
{:toc}
本文主要说明对这个博客主题的改版和代码重构的过程。这个简洁高雅的博客主题受到了很多朋友的喜欢。在写第一版界面时，我对前端并不是很熟悉，对Jekyll也不熟悉。现在距离当时也一年了，对自己当时写的代码也不太满意了，同时Jekyll如今也已经升级了，目前最新版为3.1.2。因此我在临近毕业尚未入职前做一下博客主题的代码重构和改版吧。
主要想做这些事情有：添加归档，添加标签，添加分类页面，主页显示文章摘要，代码去除 jQuery 和 BootStrap，优化移动端显示，将所有变量写入配置文件_config.yml中等。再优化一些细节吧。希望更多人会喜欢。
继续阅读 »
我们下载了Github上的代码，并仔细阅读了其中的细节。最后我们对源代码做了一些修正(新代码已上传到Github)，主要包括：
修复了代码运行中出现的一些bug
添加了一些函数，使代码更简洁
训练阶段我们采用了分批处理，优化了内存
参考论文《Extended Supervised Descent Method for Robust Face Alignment》，优化了源程序
在测试阶段，我们使用了逆的缩放和平移变换将得到的aligned_shape
转换为原始图片的特征点true_shape
添加了详细的注释，使之更容易明白。
more
Dependency:
Vlfeat library: http://www.vlfeat
继续阅读 »
1.简介
infobright是一个基于MySQL的数据仓库系统，内部是没有索引，采用的Knowledge Grid来组织数据。基本特征如下：
查询性能高：百万、千万、亿级记录数条件下，同等的SELECT查询语句，速度比MyISAM、InnoDB等普通的MySQL存储引擎快5～60倍
存储数据量大：TB级数据大小，几十亿条记录
高压缩比：理论上是40：1，在我们的项目中为10:1，极大地节省了存储空间
基于列存储：无需要物化视图、复杂的数据分区策略、索引
适合复杂的分析性SQL查询：SUM, COUNT, AVG, GROUP BY
没有特殊的数据仓库摸（比如星形模型、雪花模型）要求
和众多的BI套件相容，比如Penta
继续阅读 »
为了进一步裁剪tbox，更好的适配嵌入式开发平台，tbox新增了--micro=y的微模块编译选项
如果启用此编译选项，那么只会编译tbox里面较轻量的一些模块，是的编译后的库大小，尽量保证在64K左右。
先来讲讲一些跟库大小相关的编译选项：
* `--smallest=y`: 通用平台，最小编译模式，会禁用所有第三方依赖库，禁用所有扩展模块，启用最小化编译优化（库内部也会尽可能节省内存使用）
* `--micro=y`: 专门针对嵌入式平台设计，仅编译最为轻量的一些模块，启用最小化编译优化（有可能会包含一些可选组件）
smallest和micro的区别在于，即使启用了smallest禁用所有扩展模块，但是还是会内置比m
继续阅读 »
为了进一步提升构建效率，减少没必要的重建，xmake新增了对头文件的依赖检测，以及自动构建仅仅需要重新编译的源文件，提升编译速度，并且完全支持windows、linux、macosx等大部分平台。。
由于检测过程本身也会有一些性能损耗，因此xmake对此进行了深度优化，实现极速依赖检测：
对依赖头文件进行过滤，如果是系统头文件，非自身项目的第三方头文件，自动忽略，这些头文件基本上不会再开发项目的时候，经常变动，所以没必要去每次检测他们，如果真有变动，手动重建下就行了
针对每个头文件的检测结果进行缓存，直接应用到下一个源文件上，减少重复检测的次数
其他一些细节优化
继续阅读 »
一直以来，我们都在各种场合、各种文章中看到避免使用 RelativeLayout、避免使用过多的 layout 嵌套，因为它们存在很大的性能开销。开发的过程中也确实在留意这一点，然而每每编写 layout 文件时，都会怀疑，这样或者那样，到底会变快，还是变慢？本文就针对简单的 layout 和复杂的 layout，是否使用 RelativeLayout 的性能进行了测试，此外，还对最近很火的 FlexLayout{:target="_blank"} 也进行了测试。测试代码和测试结果数据都可以在 Github 获取{:target="_blank"}。
继续阅读 »