V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  icyalala  ›  全部回复第 36 页 / 共 191 页
回复总数  3810
1 ... 32  33  34  35  36  37  38  39  40  41 ... 191  
2023-04-19 10:43:23 +08:00
回复了 ershierdu 创建的主题 全球工单系统 小米的“动态图片”功能似乎有隐患
iOS 动态图片实际上就是一张 jpg + 一个 mov ,没什么特殊的。
楼主可以发个小米的实际样张大家分析一下。
@lesismal 先回复几个问题:

我提 UTF-8 校验说的是 string 类型的值,内部编码是 UTF-8 ,如果为了安全考虑是要做校验的。json 可以预先整个输入都校验一遍,而二进制格式需要解析出来每个 string 值之后再一一校验,不是说二进制就不考虑校验了。

simd 的支持现在都是动态派发的,就是运行时检测一次 cpuid 判断指令集,avx512 进几代 CPU 都是不降频的,不降频时才会用 avx512 ,否则还是 avx256 或继续降级,所以这个不用担心。没有 UB 的代码一般 O3 没问题,即使 O2 也相差不大。但这些都是细节,不重要。json/msgspec 性能对比其实也只能这样简单搞搞,实际应用里如果要转为用户定义的结构或者对象,耗时大头其实是在对象创建上。真要是自己用的服务又在乎性能,在 C/C++ 应用里 flatbuffer 和 capnproto 更合适,至少比自己 struct 序列化要靠谱,现在很多游戏也在用。

我认同你的后面的观点,这是市场占有率的问题。一个标准即使性能上烂,但流行到这种地步就会有越来越多的高手投入到这里来,做性能优化、做生态支持。但是一个标准用的人少,即使设计优秀,也很难吸引足够人才投入其中。
@duke807
我没看出你对 simd 或者其他数据传输格式有了解。你非要数据那我就跑一下。
以最常见的 twitter.json 作为测试数据 https://github.com/simdjson/simdjson/tree/master/jsonexamples

体积:相差并不大
json: 467KB
msgpack: 402KB

在手头 M1 上跑 simdjson 和 msgpack-c 来解析,循环 16 次
simd:dom: 759MB/s
simd:ondemand: 1604MB/s
msgpack-c: 948MB/s
msgpack 并没有明显优势,而且也没验证 UTF-8 编码。
另外如果 simdjson 在现代 x86 上跑的更快。

json 缺点一大堆,唯一最大的优点就是人类可读写,msgpack 并没有继承这个优点。
2023-04-17 12:06:31 +08:00
回复了 chai2010 创建的主题 程序员 凹语言中文语法设计
之前有段时间在 solidot 上看到过好几次凹语言的推荐,每次都要强调凹读 wa ,但我每次看到还是会下意识读成 ao 。
@duke807 看来你不明白 simd 是怎么工作的。。simd 在处理较长数据时才会优势显著,如果你把字符串拆分出来,再用 simd 校验每个字符串,就会因为需要额外对齐或者数据过短无法向量化导致性能甚至会下降的。

回头再来看看我们讨论的适用场景:如果你是对外的服务提供者,无论是为前后端还是客户端,那明智的选择是尽可能为`更多人`服务,用 json 是毫无疑问的。所谓小众格式说的并非是没人用,而是 json 已经是事实标准、占据统治地位,其他格式的支持程序、系统生态根本不在一个量级上。

如果你是给自己的系统选择数据传输格式,追修更高读写性能和更小流量,那还有 flatbuffer 和 capn proto 等所谓 0 解码耗时的 zero-copy 方案。选择 msgpack 更多的是那些过去 json 带来的惯性,并不是什么追新。
@duke807 接口方面,你不可能要求后端同学花费力气去专门为小众需求单独开发一个接口。而且即使对齐到 json 格式的话,支持多种格式也需要后端单独做开发和测试,这和运维同学改改 nginx 配置完全不是一个工作量。

我觉得性能方面你想当然了。simdjson 能用 simd 快速教研整个 json 的 UTF-8 编码,实际上现在解析速度也能达到 3GB/s ,甚至还能按需解析性能还会更高。msgpack 里面的字符串也是 UTF-8 的,但我没见有什么库愿意去写 simd 加速或者按需解析的。

如果你把应用范围限定在嵌入式,那和上面我们讨论的完全不是一回事儿了,性能又不是主要考虑的东西。如果你说没有 malloc ,那就算用 JSON 库也有很多允许自定义 allocator 或者自带 fixed memory allocation 功能的库,这完全没问题。
@duke807 如果你同时支持两种格式,那只能让功能向 json 对齐,msgpack 的额外功能就用不到,结果无非就是省些流量。如果再 gzip 一下,那两者连流量的差距都很小了,这只要在 nginx 配一下就行,对应用来说都是透明的。

如果说性能,正是因为 json 流行,现在各个语言都有一堆高度优化甚至 simd 加速的库,其他格式没这个待遇的。有特殊需求的,这里还有一堆二进制格式可选呢: https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formats
如果服务仅限自己使用,那什么格式都无所谓,甚至自定义个私有格式也许在性能上更好。
如果你要给别人用,那当然要考虑最通用的,并不是每个人都有能力或者愿意去兼容其他更小众的格式。
何况 msgpack 在性能上并没有明显优势,不一定比得上 JSON 压缩+simdjson 。

在这个 json 已经是数据交换事实标准的情况下,你给别人提供服务用 msgpack ,那才是没眼光。
2023-04-14 11:44:57 +08:00
回复了 xiaonzha 创建的主题 问与答 在公司使用谷歌浏览器,被监管
换小众浏览器,比如 Opera 、Brave 、Vivaldi 。但公司还是能记录你访问的域名和流量,只是公司一般不管罢了。
正派做法是不要再公司设备上做私人事情。。
2023-04-14 00:49:29 +08:00
回复了 2503 创建的主题 程序员 技术使用感受: JQuery 和 Vue
https://i.imgur.com/EGG7YZE.png
老夫写代码就是一把梭 /拿起键盘就是干
感觉已经是历史了
我想起日本好几年前的那个概念《低欲望社会》
经济增长停滞后的急转直下的那种社会氛围,人们失去对未来的期望。存款增多、消费停滞,人们的欲望也逐渐降低。
@alne 你脑子是怎么转的?法规出来后大部分企业还是要尽量遵守的,除非你有自信你的公司能达到 pdd 无耻的程度而且还不被查。
你作为人来写程序不可能没 Bug
AI 生成也不可能保证准确和符合价值观

但是你写了 Bug 有人能帮你测试,而且 Bug 多了顶多绩效不好
意见稿那个要不符,可是能直接把你业务关停的,说不准还要罚钱
2023-04-11 15:39:42 +08:00
回复了 kele999 创建的主题 问与答 关于 emoji 添加更多中华文化图标的倡议
可以自己去提案啊,
这是准则: https://unicode.org/emoji/proposals.html
这是请求受理情况 (信息不太透明): https://unicode.org/emoji/emoji-requests.html
2023-04-11 15:09:00 +08:00
回复了 gtheone1 创建的主题 随想 你们吃饺子都蘸醋吗
我家当地的习俗是醋+蒜泥+香油,蒜泥捣的时候可以稍微撒点盐。
和同学出去吃饭,四川的同学喜欢辣椒+蒜蓉+醋。广东的同学就喜欢酱油。

说到这里我又想起了那个梗,吃饺子不沾酱油被关监狱一年多:
https://www.163.com/dy/article/I0N784A30552QOTX.html
2023-04-11 13:27:37 +08:00
回复了 wu67 创建的主题 macOS 关于 Mac 内存多少才够用
现代版小马过河
老牛说,河水很浅,我过河完全没问题啊,别听别人瞎说。
松鼠说:这河根本过不了,亲测,那些说河水很浅的人不是蠢就是坏。
小马:反正每次都有人说过不了河,我来说一下我的经验吧...
2023-04-10 20:43:24 +08:00
回复了 pdog18 创建的主题 问与答 小而美不让图片和文字出现在同一条消息的原因是?
让图片和文字出现在一条消息里这是在想什么。。这是要写电子邮件吗?
Anker 或者贝尔金,选个喜欢的样式就行。
充电头是个品牌货都问题不大,但我给被人推荐肯定不会推荐小米倍思之类的。
2023-04-10 12:04:08 +08:00
回复了 DrLty 创建的主题 Apple IOS 的屏幕截图为什么不压缩呢?
@DrLty @est 如果单纯提供 "压缩 /原图" 显然还是有用户不满意,指责"替用户选择"。如果真让用户选择,那应该提供 JPEG/PNG/TIFF/GIF/BMP/PDF/HEIF 格式选择,并且提供压缩质量调节、尺寸调节、是否保留元数据等选项。

但这些选项在自带的快捷指令里都可以做到。
1 ... 32  33  34  35  36  37  38  39  40  41 ... 191  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1045 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 51ms · UTC 19:05 · PVG 03:05 · LAX 11:05 · JFK 14:05
Developed with CodeLauncher
♥ Do have faith in what you're doing.