关于quicklz压缩算法在游戏中的应用

    之前对quicklz算法有一定了解,知道其对单个消息包压缩比几乎没有甚至为负值(之前未测试,只是理论猜测), 故采用聚集压缩(N个消息的字节流的某一部分压缩),这样可有效减少压缩函数的调用次数,减少开销。

      今天给as3搞了个客户端网络库,调试的时候验证了以前的猜测(其对单个消息包压缩比几乎没有甚至为负值),样本数据很简单,几乎无重复的字符串,大概1K多,少了几十字节。 若一个服3K人,用一个网关,一个连接发往客户端1s发3次(一次若干消息), 这样算来,相当于1K连接,每帧都要压缩一次。  算是平均开销。 若往客户端发送的消息很多,那么会出现需要压缩若干次,也就是说若干次函数调用,不过这个情况比较少,平均来讲,CPU 开销以及带宽减少产生的收益还是比较诱人的。

测试过zlib,他的压缩比很理想,但是CPU开销很高。而quicklz 都适中吧。

平衡的把握很纠结。。。

转载于:https://www.cnblogs.com/lcinx/p/10570665.html

引用\[1\]提到了Quicklz算法是一种快速的压缩算法。一般的压缩程序会在读入文件后立即进行压缩,而不是先分析整个文件再决定采用哪种算法。在解压方面,对于level=3的情况,解压方法相对容易理解。但是对于level=1和level=2的情况,解压方法稍微复杂一些。因为压缩文件只存储了哈希值,没有指明重复的字节串,甚至没有给出偏移量。但是在解压程序,我们可以根据第一次遇到哈希值时不进行压缩的原则,得到偏移量的值。随着解压的进行,哈希值和偏移量的变化与压缩时的变化是相同的,因此不需要保存这些值也能正确解压。\[2\] 根据引用\[3\]的代码片段,我们可以看到Quicklz算法的解压过程使用了不同的解压方式,根据匹配长度和偏移量的不同,采用了不同的解压方法。具体来说,当匹配长度为3且偏移量小于等于63时,解压方法是将偏移量左移2位后赋值给目标位置;当匹配长度为3且偏移量小于等于16383时,解压方法是将偏移量左移2位并加上1,然后使用fast_write函数将结果写入目标位置;当匹配长度小于等于18且偏移量小于等于1023时,解压方法是将匹配长度减去3左移2位,偏移量左移6位,再加上2,然后使用fast_write函数将结果写入目标位置;当匹配长度小于等于33时,解压方法是将匹配长度减去2左移2位,偏移量左移7位,再加上3,然后使用fast_write函数将结果写入目标位置;最后一种情况是匹配长度减去3左移7位,偏移量左移15位,再加上3,然后使用fast_write函数将结果写入目标位置。 因此,使用Quicklz算法进行解压时,根据匹配长度和偏移量的不同,采用不同的解压方法来还原原始数据。 #### 引用[.reference_title] - *1* *2* *3* [Quicklz压缩算法](https://blog.csdn.net/QQ576494799/article/details/108889946)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v91^insertT0,239^v3^insert_chatgpt"}} ] [.reference_item] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值