我觉得这么点东西用runtime包的OS判断一下就好
它在IOS上经过测试了吗

我觉得这么点东西用runtime包的OS判断一下就好 它在IOS上经过测试了吗

Tested and works. I will change it to runtime.

我觉得这么点东西用runtime包的OS判断一下就好 它在IOS上经过测试了吗

seems only works when separated, syscall.Mmap not exist in windows and wasm.

好吧 我还以为会有类似 panic("not implemented") 之类的东西

卧槽，iOS 上能用这种好东西咋不早说

可以少一次把文件load进内存 会少一些 但是后续proto的解析还是会全部读进来 有时候启动时峰值会莫名其妙上一两百 这是一份十几二十的file造不出来的 我也不知道哪来的 最终大概还是geo file的设计问题 用proto message少不了一整个放进内存读一会(

可以少一次把文件load进内存 会少一些 但是后续proto的解析还是会全部读进来

我早写了先找到需要的部分再 unmarshal，不用全解析啊，所以先把它们切成小文件那种做法意义也不大了，基本都不缺 ROM

你这就开玩笑，如果还是全部 unmarshal 的话瞬时内存占用直接 100MB+，iOS 上跑都跑不起来

看最近的 PR 总给我一种高端武器自己从地里长出来的感觉，@hossinasaadi 可以合并了吗

你这就开玩笑，如果还是全部 unmarshal 的话瞬时内存占用直接 100MB+，iOS 上跑都跑不起来

从调用里跳到test文件了 里面还是旧的看错了

不过一个简单写了geosite:cn和geoip:cn两座大山的config峰值内存(VmHWM)还真是123136 kB
这个pr后会降到113368 kB

没这么夸张吧你这像是全 unmarshal 了，我咋记得 unmarshal 且 build 后的 geosite:cn 就十几 MB，你看静置内存多少

静置只有40mb没啥问题 不然早炸缸了

但是 build 后的 geosite:cn 才十几 MB，unmarshal 后的 proto 更紧凑只会占用更少啊，你这峰值内存顶天 50MB 才对

我不知道 别打我(
config大概是这样

{
    "routing": {
        "rules": [
            {
                "domain": [
                    "geosite:cn",
                    "geosite:private"
                ],
                "outboundTag": "direct"
            },
            {
                "ip": [
                    "geoip:cn",
                    "geoip:private"
                ],
                "outboundTag": "direct"
            }
        ]
    },
    "outbounds": [
        {
            "protocol": "freedom",
            "tag": "direct"
        }
    ]
}

命令是 grep VmHWM /proc/$(pidof xray)/status
不过也不一定低于这个数起不来 因为机器内存充足它会一起加载 不够的话他可能等大头geosite跑完再去加载geoip 就不会吃这么多(

而且不用紧凑的 proto 的话，难道直接把 build 出来的结构体 dump 到文件再叠上 mmap 然后 unsafe 一手，那就绝了

但是这个方法针对每个处理器架构都要搞一次，还好 iOS 都是 darwin arm64，@hossinasaadi 下一步可以试试这个

不过最彻底的还是把路由和出站分两个进程吧，没必要非把路由塞进 iOS packet tunnel provider

而且不用紧凑的 proto 的话，难道直接把 build 出来的结构体 dump 到文件再叠上 mmap 然后 unsafe 一手，那就绝了

这不是 把自己手动放进swap 会变慢的(

btw 这还算小问题 毕竟人们可以使用精简geofile或者减少路由条目 最近看到最多的complain是xhttp吃的ram太多无法在ios使用

一个连接才匹配一两次的东西能慢到哪去，板载 ROM 读取速度也没那么拉，又不是机械硬盘

我也看到了，可能因为 packet-up 上行自带缓存吧，因为可能有自动重传

之前 iOS 还有一个问题是没 TUN，现在 TUN 也快有了，就是不知道 gVisor 会不会占内存更多

Just saw this and I have some comments:

1. I can't find where munmap is called after doing mmap. I guess there are cases where Xray needs to update config or certificates and if files aren't properly unmapped, it can cause memory leaks, so this can't be simply ignored.

2. mmap is only suitable for handling files with low information density (such as extracting a few tags from the entire Geofile). I don't think mmap is suitable for a generic ReadFile function since most files do have high information density, in which case mmap may not be cost-effective at all.

3. Windows also have an alternative to mmap.

There is a mmap implementation in golang.org/x/exp package with support for Linux, Darwin and Windows. They provide a ReaderAt instead of returning a byte slice to avoid inproper use of the mapped memory (such as write, which is not implemented). Mapped files will be unmapped automatically via runtime finalizer, or by calling Close() manually. This could be took as a reference.

Also, you don't have to copy the whole file for build constraints. Just move it out and create seperate files for platform-specific features and leave generic logic alone.

还是得 pre-map，或者干脆就把这些优化全替换为 #5505