哦，不对，编译器优化用 asm volatile("" ::: "memory");隔开就够了，O_SYNC 配合合适的用户态 dma 映射实现，应该就足够了
（不过用户态 dma 你还是得考虑调度的问题，没准你循环写入的时候进程被调度走了呢）

虽然理论上这种情况还有编译器优化的问题，也就是如果 a b a 这样写，可能会跳过中间的 b
再用前面说的 volatile 转换方式也不迟（

@amiwrong123 参考这个 https://github.com/ikwzm/udmabuf mmap 的时候加一个 O_SYNC

@geelaw 我感觉根本不是一个目的啊，drop_caches drop 的是 page cache 这些，和 cpu 缓存一点关系都没，下文提及的也看出不太像是访问文件的问题）

不过 linux 用内核用是有正当理由的，你这是 x86 带有硬件 dma 或者别的硬件内存映射技术一类的吗，那样用户态也访问不到吧

@amiwrong123 （小寄巧：用 *(volatile int __attribute__((force)) *)&x = 1 写入
内核也在用，不过把 __attribute__((force)) 加了个宏__force 简化）

我觉得这里有很多概念上的问题啊。。。
/proc/sys/vm/drop_caches 这个显然和 cpu cache 没有关系
你要 bypass cpu cache 的话，直接 volatile 不就好了

@debuggerx 但还有一个是 scintilla 编辑控件，这个也是被直接用了（
感觉就像是进口发动机（

但核心文本编辑器控件是 scintilla （
其实我比较好奇到底啥程度才算自研，为啥 vscode 改就不能算，但用 qt 就可以算

@binfreeze
很显然和所有工程一样，软件工程也是妥协的艺术，理想主义不能当饭吃，现实中就是会有多种相互冲突的需求，尤其是不同类型的项目，需求差异更是千差万别，代码设计的再好，用户也无法察觉，只能从主观上去评估，谁会在意点下按钮，需要用几个指令周期，访问几次内存，发送几个请求才能完成呢？
说到底，最主要的问题就是，约束太多，而资源有限。就像现代无法复刻 2000 多年不倒的古罗马混凝土建筑一样，并不是现代人没能力做，而是不想分配几十万“人月”的资源去做，现代建筑设计寿命就几十年，你造 2000 年不坏的建筑有什么用呢
就像混凝土的评价指标不止是持续时间一样，代码的评价指标也不止是性能，开发成本你当然也得算进去，还有更多的指标和具体目标相关，例如互联网领域你期待能快速变更以适配风口，2C 领域你期待能实现美观的界面，2B 领域你期待数据安全保障，工业领域你期待能持续维护
当然不是所有的指标都互相冲突（比如你确实可以做得既优雅又漂亮，还有很高的性能，在主流平台都能流畅运行，还容易扩展，方便后期维护），但显然几乎所有其他指标都和开发成本/时间冲突，在成本固定，时间有限的情况下，某个方向追求越高，分配给其他方向的预算自然就更少

vscode 我记得已经内置了 profile 功能，还能在不同 profile 中可选的共享一些配置）

@MakinoharaShoko react18 有专门的 useSyncExternalStore

我建议用第三方前端解决这个问题

useEffect 里搞订阅容易在 react18 的 suspense 和异步模式中出问题

是向量搜索吗，那可能需要用一些特别的技巧
指 sqlite vss

你列的那些是反过来用的，当然不行了
搜索 linux rdp client

主要是历史问题，一开始这么做了，后面为了兼容也只能继续
历史上是性能问题（内存不够加载全部内容，只能分成头文件和实现文件）
现代 c++你是可以把所有内容全写 header 里的，所有声明都加上 inline 就可以了（然后就可以等着内存爆炸了）

因为不放广告的话大多数用户的价值是负的