请选择 进入手机版 | 继续访问电脑版

 找回密码
 点一下
楼主: 血戮魔动冰

一种新的存储结构和HASH改进算法及HandleTable运用

[复制链接]
发表于 2009-5-1 10:59:39 | 显示全部楼层
GC的主要问题不是string泄露么?
10W条的话
很容易达到的吧
回复

使用道具 举报

发表于 2009-5-1 15:31:45 | 显示全部楼层
看你一次創造的String量而定

每秒5000條String,大概5W就會嚴重Delay
每秒50條String,到了10W條還很順暢

另外Handle在刪除之後H2I會被回收利用
所以除非函數寫得相當畸形,不然10W綽綽有餘


OS用GC,信長用GC,而事實證明這些地圖也不會Delay
所以GC其實已經滿足大多數的地圖製作需求


當然我們不能停滯不前,所以才會有之後的DataSystem跟TimerHASH


HASH+Struct雙鍊、多鍊系統是目前最強的HASH
高效率是其特色,也沒有String的問題
以它為雛型,稍微擴充或改造一下,也可以擁有超過8191上限或多維陣列的效果,而效能依然無懈可擊
與DataSystem結合之後,不僅避免使用GC與String,還可以無限制的擴充容量、可儲存的變量類型
已經足夠地圖作者開發任何需要的效果


地圖Unit超過1000隻就會嚴重Delay
就算一隻Unit綁八個數據,也不超過8191,因此8191是綽綽有餘的
我還沒看過需要綁定超過8191數據的地圖,如果有也是函數寫得很差的那種


這套Location系統的效能讓人擔憂,實際儲存大量資料的時候能發揮多少效能呢...
loop裡面還有遞回呀...
回复

使用道具 举报

发表于 2009-5-2 11:44:44 | 显示全部楼层
恩,
我本身就不是学软件的
Jass也是刚学
这个东西最开始也不过是一个想法
结果发展到了这样
实际上如果硬用这个做一个通用系统的话
确实是很麻烦
自然也没有HASH+Struct雙鍊、多鍊系統好
不过问题是又有多少人用明白Struct呢?
另外
如果要做一些简单的内容
也许用Location快捷些吧
关于GC
实际上我自己也不是特别了解
迄今为止也只用过一次
很多内容都是看了别人的帖子
自己并不明了

对于VJ
实际上还是不怎么了解
另外也真的不知道它的效率如何
所以也没考虑这么多
回复

使用道具 举报

发表于 2009-5-2 14:05:48 | 显示全部楼层
Struct+HASH系統的核心函數很短,效能很高
理解不容易,使用卻不困難

之前有人發過了,晚點我也會發表我的版本
可以完全取代GC的版本

至於模擬多維陣列跟突破8191上限,有興趣的也可以自己另外寫
畢竟不是甚麼困難的東西
回复

使用道具 举报

发表于 2009-5-2 14:17:21 | 显示全部楼层
加上了Vj的转换
也少不了吧
VJ还是不会啊
恩,手上没有能用的WE
回复

使用道具 举报

发表于 2009-5-2 15:47:18 | 显示全部楼层
初始化创造10w个点。。。保证handle位不超过10w个就可以分别编。。。听起来可以的样子。。。呼呼

不过魔兽的数据量还是很少的吧。。。

用动态的点来记录的话还会增加下handle位ms
回复

使用道具 举报

发表于 2009-5-2 16:47:05 | 显示全部楼层
不用location的主要原因是因为那个东西太慢。。仅此而已
回复

使用道具 举报

发表于 2009-5-4 10:04:51 | 显示全部楼层
一次的话
比缓存快点……
不过因为是链表
所以次数很多……
回复

使用道具 举报

发表于 2009-5-11 20:14:02 | 显示全部楼层
回复

使用道具 举报

发表于 2009-5-14 09:04:26 | 显示全部楼层
。。最后一句话囧到我了。。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 点一下

本版积分规则

Archiver|移动端|小黑屋|地精研究院

GMT+8, 2024-3-28 19:39 , Processed in 0.131084 second(s), 17 queries .

Powered by Discuz! X3.5

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表