V2EX › Nazz 的所有回复 › 第 33 页 / 共 45 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 29 30 31 32 33 34 35 36 37 38 ... 45

❮

❯

2023-03-13 11:19:56 +08:00

回复了 Nazz 创建的主题 › 分享创造 › golang 分享: 60 行代码巧妙实现一个高性能无 channel 任务队列

@rockuw 从你的 Benchmark 结果来看, 差距不大. GwsWorkqueue 是专门为 IO 任务设计的, 每个 WebSocket 连接上有读写两个任务队列, 它们非常轻量, 而且并行读写不会新增常驻协程. 量变产生质变, 每个连接上都增加常驻协程会使 CPU 使用率提高不少. 实际业务中并发不会很高, 可以用优先队列替代普通队列减少 allocs, 收益不高我懒得去优化了, 复用 goroutine 对于 IO 任务收益也不大.

2023-03-12 09:59:57 +08:00

回复了 wuqiwen 创建的主题 › 分享创造 › 我开发的微信小程序「恋上古诗词」上线了，还请帮忙多提些意见

全栈大佬

2023-03-06 10:38:00 +08:00

回复了 SuperMild 创建的主题 › Go 编程语言 › 有了泛型，以前一直想做的 Go 错误处理终于可以实现了

看起来还不错

2023-03-05 13:16:43 +08:00

回复了 Nazz 创建的主题 › 分享创造 › golang 分享: 60 行代码巧妙实现一个高性能无 channel 任务队列

@chuanqirenwu 刚实现的 client ，还在测试

2023-03-05 08:18:48 +08:00

回复了 Nazz 创建的主题 › 分享创造 › golang 分享: 60 行代码巧妙实现一个高性能无 channel 任务队列

@chuanqirenwu 确实有 EventLoop. 最开始我是模仿的 JS, 因为我认为 JS WebSocket API 比 gorilla/nhooyr 这些提供的都要清晰得多. 初版只有 Sync IO, Read=>Event Handler=>Write 循环往复. 后面在此基础上加了 Async IO, AIO 模式在每个连接上有读写两个任务队列(并发度分别是 N 和 1), 就是我分享的这个实现, 它需要足够的轻量. 两种模式压测表现都比 gorilla 好得多, 原因大概是 Parser 本身的简单高效和无额外常驻协程吧, 如果有, 协程数量会增加一倍.

2023-03-05 07:43:55 +08:00

回复了 Nazz 创建的主题 › 分享创造 › golang 分享: 60 行代码巧妙实现一个高性能无 channel 任务队列

@MindMindMax 尽量使用 mutex 替代 chan. 很多时候保证线程安全就行了，不需要多线程通信. channel 我用得最多的地方是线程同步和超时控制.

2023-03-04 23:13:29 +08:00

回复了 Nazz 创建的主题 › 分享创造 › golang 分享: 60 行代码巧妙实现一个高性能无 channel 任务队列

@chuanqirenwu 同步模式没开额外协程，异步模式会开非常驻的协程，执行完任务就退出, 两种模式都没使用 channel.

2023-03-04 09:11:23 +08:00

回复了 liul2566 创建的主题 › 程序员 › 面试官：你认为你相比于其他候选者的优势是什么？

待遇要求低, 身体好能加班

2023-03-04 07:56:16 +08:00

回复了 Nazz 创建的主题 › 分享创造 › golang 分享: 60 行代码巧妙实现一个高性能无 channel 任务队列

@rrfeng 另外几种"协程池"都用了 channel