hyb
> 下面测试替换我实现的hash map. 性能提升比较明显https://github.com/ktprime/emhash/blob/master/hash_table5.hpp > > D:\timer-benchmarks-master\test\BenchTimer.cpp relative time/iter iters/s > ============================================================================ > PQTimerAdd 17.27ms 57.89 > TreeTimerAdd 76.74% 22.51ms 44.42 > WheelTimerAdd 113.68% 15.20ms 65.81 > ---------------------------------------------------------------------------- > PQTimerDel...
1. 时间轮事件删除时立即从哈希中删除，在触发中延期统一删除可能使得hash map一直变大（我的测试10%影响，先大量加入然后大量删除的应用场景） 2. 时间轮事件执行中立即把taskl状态设置为false，因为callbak中可能删除当前执行的定时器，使得size计算不对变成负数（测试遇到了,size 变量可以删除用hash map计数） 3. cancel 时间轮的事件可多次执行。需设置task事件状态为fasle或从hash中删除 4. tick中执行了2次execute，可以减少一次调用（简单做在外部循环外调用一次，调用一次就行）。 5. cascade 重新添加事件要过滤已失效的
the best string hash function for hash map. https://github.com/wangyi-fudan/wyhash from benchmark your str win is because fixed size string(no heap alloc -> cache friendly) and opt string compare I add...
bytell_hash_set's rehash is not expected load factor. My flat emhash can set load factor to 1.0 I have update dynamic_rehash_effect.cc. ``` static void high_load() { size_t maxSize = 1U
from my bench facebook's folly::F14VectorMap is more effiect than F14ValueMap(I don't know why many thirdparty benchmark do not test it), it's load factor can set 1.0 without any performance loss.
random Insert and erase **begin** is a quite interesting benchmark I think you know why some hash maps maybe very slow and others are quite efficient. ``` #include "Map.h" #include...
在我的quic 网络库中，单个用户连接存在6-8个左右定时器(重传，延时发包，心跳，idle，ack, blackhole, send_flush ...)，统计显示95%以上的操作删除和插入，真正触发非常少(活跃的ack和重传)，每秒10w+次基本操作，需要超高性能的定时器毫秒精度设计方案。 上面各种方案或多或少存在应用场景限制，比如时间轮定时器存在如下缺陷 第一：存在空转现象，尤其是定时器不多，触发分布不均匀 第二：无法O(1)取到最小时间触发点 (比如网络库中 epoll 常用最小触发时间作为超时参数) 另外堆和红黑等实现中高频繁插入删除性能比较差 ，内存局部性性能不友好 我结合时间轮和4叉堆两种不同实现方案整合一直新的定时器， 基本能满足各种设计要求, 时间轮第一级(比如 256 毫秒内)用4叉堆实现。堆的大小至于太大，活跃的定时器基本都在堆中， 时间轮每256 ms更新一次堆中数据。 ``` #pragma once #include "util/heap_timer.h" #include "util/wheel_timer.h" // timer queue...
Hi I have got the prime sieve benchmark on http://ntheory.org/sieves/benchmarks.html. can you add and test https://github.com/ktprime/ktprime/blob/master/PrimeNumber.cpp to your form? from my bench it's fast than most others.
完整编译后大小
你这个没裁剪估计大于50M 我花了3个月做成跨平台的cmake的libquic，不带http和tls证书校验功能，使用上和tcp api基本一致，编译后的libquic大小6M多。对于移动平台也算是巨大的
可以把我实现的lru 加入你的测试（集中删除）https://github.com/ktprime/emhash/blob/master/lru_size.h 过比传统实现hashmap+list 快4倍。一个单一数组实现的hash，不算严格的lru。