试试上古快捷键: ctrl+insert / shift+insert

@jamfer #16 流畅的 不卡顿 就是 GPU 占用乍一眼看着有点高

#14 typo: 静止不动

海港那个图禁止不动时候的占用: Apple M4 三个 GPU 核心 每个核心 70%+

站在用户角度来看: 为什么不考虑精简代码和第三方依赖库呢 把 apk 整包的 size 减小了 编译也会快呀

站在技术角度来看: 非常棒的思路和实现

如果部署流程健壮的话 能"新机器替换现有的"吗？直接用新机器部署一遍 旧机器刷机掉 等待下一次操作

datagrip

https://github.com/bytebase/bytebase

datagrip 非商用已经是免费的了 你这个插件和官方的对比 有什么差异性吗？

是否可以通过 github action 做一下自动化打包？

推荐一个我自己的库:

https://github.com/valord577/mailx

以下仅个人工作相关的观点哈:


1. 如果是自有的产品 能完全掌控部署和编译环境 那么只要内部团队协商好就行。
2. 如果是提供 sdk 动态库给客户用，一定是提供 c 的 api 。原因有二，abi 稳定 客户可以用自己的编译器 / api 符号稳定。至于 sdk 内部语言用 c 还是 c++都无所谓 如果用 c++实现的 sdk 切记打包静态 c++运行时(libstdc++.a/libc++.a) 不然客户那边会有一大堆问题

你可以问一下你身边的"模型制作者"几个问题。1. 什么是傅里叶变换 2. 傅里叶变换为什么能在神经网络中起作用 3. 神经网络的本质是什么 (是拟合结果 y = f(x)仅此而已)

我身边的模型制作者 都是用开源网络结构 训练一下 调参一下 然后把测试集输入模型 看看效果。不行再重复前半句的操作。

至少我身边都称"模型制作"就是炼丹。99%的模型制作人回答不上上面的 3 个问题。

反而是 像你这种能把模型进行工程化落地到实际项目的人 能为公司带来收益。 所以不需要妄自菲薄。仅仅是炼丹的入门 你也是可以入门的。

盲猜原因是 swap 占用太多磁盘 可以用这个命令查看 swap 信息: sysctl -a | grep swap

至于 IDEA 还是得配置一下 jvm 的最大内存占用 配置信息引用这个帖子 https://www.v2ex.com/t/1117622#r_16005722

PS: -Djava.compiler=NONE 拼错了

看 OP 发帖的目的是"闲聊" 还是"获得市场行情的信息"了

我个人主观觉得 得先认清自己的"目标" [doge]

具体情况还是得拿出日志和 jvm logs 来分析 以下只是猜想:

1. java 运行期间会做 jit 储存 jit 也有个 size 当这个满了后 会导致卡顿
2. 默认的 gc 在回收内存时 会导致卡顿

下面是我的 idea.vmoptions 仅供参考

-Xms1024m
-Xmx2048m
-XX:+UseZGC
-XX:SoftRefLRUPolicyMSPerMB=0
-Dfile.encoding=UTF-8
-Djava.complier=NONE
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-XX:+IgnoreUnrecognizedVMOptions
-XX:+UnlockDiagnosticVMOptions
-ea
-Dsun.io.useCanonCaches=false
-Dsun.java2d.metal=true
-Djbr.catch.SIGABRT=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-Djdk.attach.allowAttachSelf=true
-Djdk.module.illegalAccess.silent=true
-Dkotlinx.coroutines.debug=off
-Dapple.awt.application.appearance=system

-Dnosplash=true

-XX:ErrorFile=$HOME/Downloads/java_error_in_idea_%p.log
-XX:HeapDumpPath=$HOME/Downloads/java_error_in_idea.hprof

amd ffmpeg 建议集成这个 而不要走 va-api

https://github.com/ROCm/rocDecode

强行喝水 有尿意就会去上厕所 减少尿酸还能走动走动

@132