而且仔细看才发现，你这 rd.readlines()函数调用的时候就已经全部读到内存了。

很久没接触 Python 了，看不太懂 arr.extend
你这一行是 56 个字符，加一个回车一行 57 个。都是 ascii 算一个字节。一行就 57 个字节。算一百万行，就是 57x100x10000/1024/1024=54.3MB ，这么小的量。
直接读进来放内存里，一秒都不到，明显是你这处理方式有问题。

@yuthelloworld 我的感觉：
其实如果是公司项目的话，就 antd 全家桶、umi 、dva 啥的就好了。阿里怎么来我就怎么来，资料多、别人也好接手。跟不跟，用什么都无所谓，反正大厂选了，停止维护吃亏得也不止我。
但想写 React 个人项目的时候就比较纠结了，因为个人不做管理系统，antd 就不用了，用不上 umi 那一套。而且框架选择可以更激进，更注重开发体验，就很纠结用啥。

intel 16 寸 mac 带独显。
Bootcamp 装 win 11 能玩只狼，有点卡，降点分辨率应该算能玩的水准了。估计前几年的 3a 也能玩玩。
不过只是拿来测试，正经人谁拿 mac 打游戏啊。

想看看是啥软件

工作中根本不用，但你得会。
框架不懂原理也就算了，js 的基础还是得打牢啊。

UUID ？

没画过散点图，我这边 ECharts 画折线图，20000+数据也是秒画。卡顿主要是后台数据库查询了。

你可以先试试看一次查询的，性能问题最忌讳虚空打靶。
看看后端 Java 、数据库、网速、体积、内存、js 、ECharts 到底哪个占了最大头的部分。这样才能针对性优化。
500 条数据感觉属实有点少了，跟 #13 说的至少加个 0 ，现在计算机的性能真的挺强、挺快的。

再者说也不用等返回完了再画出来吧，如果每条数据是独立的，那完全可以有的部分先画出来。我记得 ECharts 对过渡动画和在线数据更新也支持得不错的。

楼上的学到了^_^
最近正好也有做大量数据展示，我怎么就一直没想到分块查询的思路呢。。。

你这树莓保熟吗？

React 就是这样的，吐槽的都累了。

感谢分享。但个人感觉确实不好看，有种包着、闭塞的感觉。
JB 图标虽说确实是“棱角分明”，但是是折纸多边形的，不是正四方，个人感觉挺好的。

去看看过去的科幻片就知道了。科技发展没那么快，而且 5 年太短了。

同意楼上的，可能就是解码性能不行。
我家电视刚买回来的时候，下了部一百多 G 的狂怒，usb3.0 直接接 u 盘播放，卡的一批。
买了个外置盒子瞬间流畅。

跟官方反馈啊，人越多越好。我已经反馈了（那个小电视的群已经满了，直接找人工客服反馈）
用的云视听小电视官方最新版。没试过在电视上搜，我是手机搜到后投屏上去的。能看，但没有外挂字幕，跟港澳台应该没关系，就是字幕的问题。

微博是真的没有人工客服。
最开始注册过一个微博账号，很久没用了登不上了，就想联系下客服。但在网页上就像#4 说的那样完美闭环，申诉要登录，但没账号根本登录不了。（其实是网页上有个按钮，无论怎么点都没反应，猜测应该是要登录才行的）
打了官方电话，各种渠道都是让你去网上申报，教你自助办理的，根本找不到人工客服。后来也不知道在哪儿找到个电话才打了进去（这个电话好像本来是处理广告、造谣还是什么侵权问题的，记不清），总算找到个真人。说了半天跟我说之前的账号 ip 有问题，只能让我重新注册一个。（这理由我觉得也是瞎扯）

所以我的决定是弃用微博。
微博常常有宕机事件，以前我一直以为是不可预测、突如其来的大流量导致的。这件事以后我改变了看法，微博就是产品做的烂罢了，而且是稀烂。

火绒。
当初装这个玩意儿主要就是为了让 windows defender 闭嘴。
我个人感觉裸奔都没事，但有个杀软还是安心点。
（个人使用基本就是不会下来源不可信的软件，但工作中偶尔不得不装一些来源不明的软件）

我也在奇怪这个问题，毕竟官方本来就有你的 ip ，完全不影响。现在只是谁都能看到了而已，只是口嗨、造谣、跟人对线成本更大了吧。