这活你发到易语言或者按键精灵论坛上， 估计 2k 都不用。哈哈。

@polandeme 那你慢慢研究吧。 首先确定客户端发送数据的字节序， 可能是 Little-Endian 也可能是 Big-Endian。
这个之后，再确定数据类型长度， 一般来说是可以解释的。

可能是字节序不一致。
这种跨编译语言的数据传输， 最好用文本格式，例如 json。或者支持跨平台的二进制格式， 例如 protobuf

@a523860 在安骑士页面左下有个“告警配置”， 可以关掉。

告诉你有漏洞， 还得先买服务才能知道漏洞列表， 真特么鸡贼。
还好后台能关掉提示。

正在关注。 书看不下去， 直接去参加比赛边学边玩了。

找到占 cpu 的进程， 查看其线程列表。 通过线程切换次数变化来大体判断占 cpu 的线程， 查看线程对应的模块。

对

用 slb 或反向代理，不暴露真实 ip。
只把入口 ip 发给可靠的人。

最近在参加阿里天池的数据分析比赛， 真的是有差距。
楼主可以先试试。

如果在浏览器执行， 怎么操作本地文件，调用系统 API 呢？
如果在独立应用内执行， 那也先得有应用啊。

@zengzizhao +1， 要是上线后留存、付费不好。各种瞎分析，无头苍蝇的优化会更折磨。

@realpg 一般开始游戏时会对时。 另外心跳计算延迟跟两边时钟差距没关系啊，本地计算发送时间、接受时间即可。

@h4x3rotab
@ccpp132
以 id 为节点构建字典树或 dfa 有个比较大的困难。由于 rule 每段的 id 数较多，节点数很快爆炸。例如一个 10 段， 每段 100 个 id 的 rule， 按正常做法节点数是 100^10。

如果改为共用节点， 即 100+100+100。。。的方式， 由于 id 重叠，又会在多个 rule 之间造成混乱。

例如下面 2 个 rule 构造树：

rule1 = [[1, 3], [2]]

rule2 = [[1, 6], [2], [4]]

rule1 和 rule2 共用了 1，2 节点。但是 3 和 6 也连到 2 上，2 又连到 4 上。 这样 4 节点没法判断到底 rule1 还是 rule2。

现在看来， 可能先得划分好 rule 的数据， 才能进一步处理。



@vegito2002 #4 #6 就是这个想法，效果有限。

@h4x3rotab 先前我想的是以段为节点构建字典树或 DFA，这样因为段内 id 有重叠，不满足查找性质。
不过如果用 id 作为节点， 可能是个好主意。

@imn1 在我的机器上，一次处理跑下来要 15 秒左右。整个数据库迭代一次耗时近 10 天。大头就在这个匹配上了。
我对 numpy 不熟，因为还有些通配符的处理，不晓得是否适用。

append 里主要想说 rule 段内 id 是以 set 方式存放的， 在预处理阶段已经将 id 组编号转换为 id set 表。
但如#6 所说， 段内 id 存成一个大 set， 相对于多个小 set 只有在首段有较为明显的效率提升。

为简化讨论， 这里就当一个段是一个 set 好了。

@vegito2002 假设查表消耗为常量。arr 长度为 n， 那么直接检索查表次数为 n 次。
而你的办法， 一次比较需要两次查表，查表次数为 2n 次哦。

@momocraft 忘了说了，段内本身就是 set 存储的。

@momocraft arr 数组 10 万左右，rule 现在近 2000 条。你说的方法，将 rule 段内拼合成唯一表， 我也尝试过，只有首段有些效果，后续段提升不明显。原因可能是 10 万条 arr 中，最终匹配的只有 10%左右， 大部分在 rule 首段就失配了。