wxf666 最近的时间轴更新 wxf666 最近的时间轴更新 |
wxf666V2EX 第 280897 号会员，加入于 2018-01-08 18:22:24 +08:00今日活跃度排名 5759 |
| 内嵌浏览器（CEF）有时会崩溃白屏。如何在崩溃时，保存一份 JS 和 DOM 堆内存快照呢？ Electron • wxf666 • 121 天前 • 最后回复来自 yyzh | 1 |
| 数据库新手求问，用于解决树形结构存储的闭包表，为何能快速获取某个节点的祖先节点/父节点/子节点？ MySQL • wxf666 • 2022-10-29 08:33:48 AM • 最后回复来自 wxf666 | 21 |
| 为什么这样写无法连接(join)数组各项？ Bash • wxf666 • 2022-09-10 00:25:51 AM • 最后回复来自 hxy100 | 3 |
wxf666 最近回复了
3 天前 回复了 chenjackyaya 创建的主题 › Windows › 微软即将推出“召回”功能来帮助 Windows 用户回溯操作 |
3 天前 回复了 irihiyahnj 创建的主题 › 信息安全 › 用了 23 年的 QQ 被盗了 |
4 天前 回复了 dedad558 创建的主题 › 程序员 › 不得不吐槽一下国内 AI 审查了, 动不动报敏感内容, 没办法稳定运行 |
4 天前 回复了 Zaden 创建的主题 › MySQL › mysql 如何高效获取两条相邻推送时间间隔 |
@ys1992 #10
我又改了改，速度提升到，仅 0.2 秒了。。
原来大部分时间，都在遍历这张一亿数据的表，查有哪些独立的 point_id 了。。
如果有 point 表，直接从里面抽出所有 point_id 即可。我是手动用 generate_series(1, 100) 模拟的。
@Zaden #22：
可能你和我原因一样，想分组 point_id ，查最后时间，数据库居然扫全索引去了。。
其他快的原因，我觉得就是，不断跳来跳去，直接查最接近 24 小时前的时间，而不是每两条时间一一对比。
这需要高度依赖 4K 随机读取。比如，浏览器里运行数据库时，会将数据留存在内存里，自然快一些。
- 本地上测试，同样缓存在内存里时，只需 0.1 秒
- 7 年前垃圾固态上（顺序读 420 MB/s ，4K 随机读 25 MB/s ），且清除系统对文件缓存后，需 10 秒
- 10 年前硬盘上（顺序读 150 MB/s ，4K 随机读 0.65 MB/s ），也清除系统对文件缓存后，需 80 秒。。
我也不知道，为啥硬盘 4K 随机读，比固态差近 40 倍，但耗时才慢 8 倍。。
可能夹杂着一些顺序读取（比如有时跳到相邻页上了？），使得差距没这么大吧。。
总之，我浏览器里都能缓存一亿数据（约 1.3 GB ），对你来说应该也不是啥难事的。
## 0.2 秒截图
我又改了改，速度提升到，仅 0.2 秒了。。
原来大部分时间，都在遍历这张一亿数据的表，查有哪些独立的 point_id 了。。
如果有 point 表，直接从里面抽出所有 point_id 即可。我是手动用 generate_series(1, 100) 模拟的。
@Zaden #22：
可能你和我原因一样，想分组 point_id ，查最后时间，数据库居然扫全索引去了。。
其他快的原因，我觉得就是，不断跳来跳去，直接查最接近 24 小时前的时间，而不是每两条时间一一对比。
这需要高度依赖 4K 随机读取。比如，浏览器里运行数据库时，会将数据留存在内存里，自然快一些。
- 本地上测试，同样缓存在内存里时，只需 0.1 秒
- 7 年前垃圾固态上（顺序读 420 MB/s ，4K 随机读 25 MB/s ），且清除系统对文件缓存后，需 10 秒
- 10 年前硬盘上（顺序读 150 MB/s ，4K 随机读 0.65 MB/s ），也清除系统对文件缓存后，需 80 秒。。
我也不知道，为啥硬盘 4K 随机读，比固态差近 40 倍，但耗时才慢 8 倍。。
可能夹杂着一些顺序读取（比如有时跳到相邻页上了？），使得差距没这么大吧。。
总之，我浏览器里都能缓存一亿数据（约 1.3 GB ），对你来说应该也不是啥难事的。
## 0.2 秒截图
5 天前 回复了 Zaden 创建的主题 › MySQL › mysql 如何高效获取两条相邻推送时间间隔 |
@ys1992 #10 不一定要扫全表吧。。
不断根据索引，查最接近 24 小时前的推送时间，应该只需要检查很少数据量，就能算出来了？
@Zaden 我用最垃圾的 SQLite ，在七年前的 i5-8250U 轻薄本上，效率一般的浏览器 wasm 环境里，试了下，
100 设备、一亿数据（每分钟推送、持续两年），每设备断线十次，每次 1~2 天，
只需 7 秒，就能全找出来了？
## 截图
## SQL 测试代码
```sql
-- V 站吞空格，缩进改成全角空格了
-- 建表，当 (point_id, push_time) 索引用
DROP TABLE IF EXISTS data;
CREATE TABLE data (
point_id INT,
push_time INT,
PRIMARY KEY (point_id, push_time)
) WITHOUT ROWID;
-- 添加一亿条数据（ 100 设备、每分钟推送、持续两年）
INSERT INTO data
SELECT point.value, time.value
FROM generate_series(1, 100) point
JOIN generate_series(
unixepoch('2024-05-24', '-2 year'),
unixepoch('2024-05-24'), 60) time;
-- 删掉断线数据（ 100 设备，每台断线 10 次，第 N 次是 id*N 天前，持续 1, 1.1, ..., 1.9 天）
DELETE FROM data
WHERE (point_id, push_time) IN (
SELECT point_id, push_time
FROM generate_series(1, 100) point
JOIN generate_series(1, 10) nth
CROSS JOIN data
WHERE point_id = point.value
AND push_time >= unixepoch('2024-05-24', format('-%f day', nth.value * (point.value + 0.1) - 0.1))
AND push_time < unixepoch('2024-05-24', format('-%f day', nth.value * point.value - 1))
);
-- 循环每个设备，从今天开始，不断往前找，最接近 24 小时前的推送时间
-- 若俩时间 >= 24 小时，则属于断线过久
WITH RECURSIVE
t(id, a, b) AS (
SELECT point_id, unixepoch('2024-05-24'), NULL
FROM data
GROUP BY point_id
UNION ALL
SELECT id, ifnull((
SELECT min(push_time)
FROM data
WHERE point_id = t.id
AND push_time > t.a - 86400
AND push_time < t.a
), (
SELECT max(push_time)
FROM data
WHERE point_id = t.id
AND push_time < t.a - 86400
)), a
FROM t
WHERE a
)
SELECT
id "设备 ID",
datetime(a, 'auto') "最后在线",
format('%d 天 %d 小时 %d 分钟', (b-a)/86400, (b-a)%86400/3600, (b-a)%3600/60) "断线时长"
FROM t
WHERE b - a >= 86400
ORDER BY id IN (1, 2, 73) DESC, id, a DESC;
```
不断根据索引，查最接近 24 小时前的推送时间，应该只需要检查很少数据量，就能算出来了？
@Zaden 我用最垃圾的 SQLite ，在七年前的 i5-8250U 轻薄本上，效率一般的浏览器 wasm 环境里，试了下，
100 设备、一亿数据（每分钟推送、持续两年），每设备断线十次，每次 1~2 天，
只需 7 秒，就能全找出来了？
## 截图
## SQL 测试代码
```sql
-- V 站吞空格，缩进改成全角空格了
-- 建表，当 (point_id, push_time) 索引用
DROP TABLE IF EXISTS data;
CREATE TABLE data (
point_id INT,
push_time INT,
PRIMARY KEY (point_id, push_time)
) WITHOUT ROWID;
-- 添加一亿条数据（ 100 设备、每分钟推送、持续两年）
INSERT INTO data
SELECT point.value, time.value
FROM generate_series(1, 100) point
JOIN generate_series(
unixepoch('2024-05-24', '-2 year'),
unixepoch('2024-05-24'), 60) time;
-- 删掉断线数据（ 100 设备，每台断线 10 次，第 N 次是 id*N 天前，持续 1, 1.1, ..., 1.9 天）
DELETE FROM data
WHERE (point_id, push_time) IN (
SELECT point_id, push_time
FROM generate_series(1, 100) point
JOIN generate_series(1, 10) nth
CROSS JOIN data
WHERE point_id = point.value
AND push_time >= unixepoch('2024-05-24', format('-%f day', nth.value * (point.value + 0.1) - 0.1))
AND push_time < unixepoch('2024-05-24', format('-%f day', nth.value * point.value - 1))
);
-- 循环每个设备，从今天开始，不断往前找，最接近 24 小时前的推送时间
-- 若俩时间 >= 24 小时，则属于断线过久
WITH RECURSIVE
t(id, a, b) AS (
SELECT point_id, unixepoch('2024-05-24'), NULL
FROM data
GROUP BY point_id
UNION ALL
SELECT id, ifnull((
SELECT min(push_time)
FROM data
WHERE point_id = t.id
AND push_time > t.a - 86400
AND push_time < t.a
), (
SELECT max(push_time)
FROM data
WHERE point_id = t.id
AND push_time < t.a - 86400
)), a
FROM t
WHERE a
)
SELECT
id "设备 ID",
datetime(a, 'auto') "最后在线",
format('%d 天 %d 小时 %d 分钟', (b-a)/86400, (b-a)%86400/3600, (b-a)%3600/60) "断线时长"
FROM t
WHERE b - a >= 86400
ORDER BY id IN (1, 2, 73) DESC, id, a DESC;
```
12 天前 回复了 yunv2 创建的主题 › 程序员 › 关于 cpu 性能和 Java 编译速度的问题 |
@liprais #32 和楼主问的并不 100% 相关，只是有些联系。
想问的就是，Java 编译应该已经足够快了，还这么在意这个干啥？
就好比，现在 CPU 内存 硬盘，都很强了，结果还有人天天在意，PC 软件那几 KB 体积啥的。。
见到这种情况，你不会产生疑问吗？
想问的就是，Java 编译应该已经足够快了，还这么在意这个干啥？
就好比，现在 CPU 内存 硬盘，都很强了，结果还有人天天在意，PC 软件那几 KB 体积啥的。。
见到这种情况，你不会产生疑问吗？
12 天前 回复了 yunv2 创建的主题 › 程序员 › 关于 cpu 性能和 Java 编译速度的问题 |
不懂就问，Java 编译很复杂吗？不是简单翻译到字节码而已吗？
复杂的应该都在 JIT 时吧？搜集信息，实时优化，编译成 CPU 指令啥的？
那应该能参考 TinyCC 的编译速度？毕竟这货也不怎么优化代码，效率和 gcc -O0 相当。。
即，二十年前的 奔腾 4 CPU ，能（单线程）每秒编译 100W 行 C99 代码成 x86 指令？
那 Java 项目即使有过亿行代码，现代 8 核电脑，最多不也就等待 10 秒钟，就能编译完成了吗？
楼主为啥那么在意呢。。
复杂的应该都在 JIT 时吧？搜集信息，实时优化，编译成 CPU 指令啥的？
那应该能参考 TinyCC 的编译速度？毕竟这货也不怎么优化代码，效率和 gcc -O0 相当。。
即，二十年前的 奔腾 4 CPU ，能（单线程）每秒编译 100W 行 C99 代码成 x86 指令？
那 Java 项目即使有过亿行代码，现代 8 核电脑，最多不也就等待 10 秒钟，就能编译完成了吗？
楼主为啥那么在意呢。。
Select Language