……所以说到底你的RCA比JPS+快是脑测的是吧？这你能这么自信说出来比JPS更快我是没想到的。有数据支撑都得想想是不是用例不够完善，你没数据都能这么自信吗？怎么做到的？
我容许他有正常的性能差距，但是数百倍我不认可，而且既然是拿来商用的，它用局部证全部本身就是悖论。还有，单机游戏的寻路，其实对耗时没有那么大要求，基本15ms左右无感知，而多人竞技类游戏，寻路是放服务器的，要做到5ms及以下
如果他在高精度的地图上连99%的15ms都稳不住，那么我只能认为这是个玩具
@3264876581 按照作者的标题【比“A星寻路”和“跳点寻路”更快】，我觉得作者只要能证明自己的泛性能（不要求100%场景）比这两个要好就没毛病。至于你们两的比较，我觉的还是要【公平公正比较好】，不然都是白扯，两边都不服气
1赞
对性能的把控只能通过感知对比？不是通过运算次数证明吧（也就是时间复杂度）？
15毫秒就是一帧，你说无感知？30个人同时在一帧寻路，游戏立即掉帧一半，你说没感知。还有你说的遍历几千上万次没感知就是效率好，你的算法用javascript在web端跑一次看看，到现在你对程序的时间消耗还是停留在“物理时间”。
这也太牛逼了
。。你是不是根本没上线过商业游戏，谁家好人在主线程寻路啊
知不知道什么叫地图实例复用啊，你连为什么要降低耗时的本质原因都不清楚，你以为30个人要开30个实例寻路?
大伙别吵了，你们都比我好多了，现在的我连A星都忘了怎么写了
今天股市又亏的一塌糊涂 
我开始的时候就让你把从死胡同寻路出来遍历过多少个格子的数量提供出来，你却说打印信息影响感知时间，我要的是数量，你却回答时间，完全是答非所问。好了现在再希望你提供一次。我就当你的物理时间消耗是0，你就直接提供给我一共计算了多少个格子的总数。
我不信你这种遍历几千次才能寻到路的算法能用到商业游戏。
。。那你的意思是，时间是假的，格子是真的是吧。我说了，格子数减少到一定程度会导致初始路径偏移，你就当我3W个又如何，你连贪心算法本质怎么贪都不清楚，更别说优化了。而且一味地追求少格子有啥用啊，商业游戏要的是综合性的适配，你只是还没遇到复杂的地图
我问的检测格子数量跟消耗时间是两个概念，我只要格子检测数量，时间不用提供给我，我可以当时间消耗是0，这样你不用纠结你的时间，只需把数量提供给我。
你的回答就像：别人问你几岁，你却说答你体重100kg，牛头不对马嘴。
说到运行时间，运行时间是不会假，但是你要在相同的运行环境对比才行。
你的代码用go语言在服务器跑，寻路检测10000个格子，可能只花10毫秒。你用javascript实现，在移动平台，特别是微信小游戏的客户端平台运行，那差距可是1000倍的，本来服务器消耗10毫秒的寻路到h5小游戏平台可能花10秒。
移动平台游戏和h5小游戏平台占主流，我希望你的寻路算法别只跑服务器，也该拿到移动平台和h5平台跑跑，看看真实的消耗时间是多少。我写的RCA寻路做过验证了，在性能最差的h5平台对付10000个格子的大地图寻路也只消耗几毫秒。
期待你能在性能最差的h5平台跑一下你的寻路，做个h5应用让我测试一下你的寻路，看看你说的是不是真的。
好像股市是因为日本在搞事情，我也炸了
你截图你的代码，看到有这个ResetMap，就知道你的算法是个啥成分了。
每次寻路都要重置一次地图，重置的应该是格子的 f,g,h状态，可能还有其它状态值，10000个格子就要重置10000次。因为你没有感知，或者感知是几毫秒，所以觉得寻路效率高，你是凭自己的感知感觉和消耗物理时间做效率判断的，你觉得只要感知没问题遍历几万个格子也是没问题的。你完全没有程序设计的“时间复杂度”的概念。
而且你的感知是依据go语言的服务端做判断的，服务器可以配置很高，不用跑其它应用也不用跑渲染，可以单独跑某个游戏服务器，这样的情况下对遍历几万格子的消耗根本九牛一毛，你当然没有感知。你在移动客户端跑你的算法就有感知了。
A星寻路我也写有，每次寻路是不用重置地图的，用的是二堆叉管理openlist，用标志位标记是否在openlist还是closelist，效率不会差。
666，你不了解go数据结构我不怪你，不过你通过一个方法名就能清楚里面写的是什么那你真神人了，我说了你的用例在我这覆盖率10%都难说，不想再重复了
这是最普通的A星百万格
这是我开启cross的百万格
你先多拿几个用例试试吧
别拿几W格说事了，我说了，在我这，0感知
围观上了，看大佬们争锋。
看了整遍， 我觉得你要打败对方至少要和对方同一平台环境吧， js 和 go差距， 只説一个数组， go 的数组是内存连续分布， 能减少cpu cache miss， 但js 的数组基于v8平台也只能尽量保证内存分布连续， 在这方面大量数据存取两者语言就有好大差距，更别説编译层问题， 一个直接与设备沟通，一个要靠c++再和设备沟通。另外你提到用线程寻路， 要知道js没有线程概念， worker 是一个子进程， 不像go专为多线程而生， 线程和进程有甚麽差距懂的都懂。 所以説你概然是发起挑战的人， 那麽你应该在cc实现你的寻路再与别人对比。语言之间的微差距在大型项目中会指数级放大， 不然ue和unity直接都用js不香吗？无视语言差距在diss就是耍流氓， 你觉得对方算法差在用语言差距做借口那麽你换平台在对方领域下把ta打下去对方不就心服口服了， 这様鸡与鸭对喷是没有意义。
8赞
地图实例是指数据实例，这个肯定是复用的。寻路是基于这些地图数据运算，每次寻路是独立的。
你难道说：地图首次寻路消耗时间，之后的寻路不再消耗