V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  iamtuzi3333  ›  全部回复第 4 页 / 共 10 页
回复总数  181
1  2  3  4  5  6  7  8  9  10  
2025 年 5 月 13 日
回复了 iamtuzi3333 创建的主题 程序员 如何一次性传输海量浮点数
@rrfeng 现在解决好了,直接二进制传输,40M ,都是在本地,带宽影响倒是不大。
谢谢各位大佬!!!
2025 年 5 月 13 日
回复了 iamtuzi3333 创建的主题 程序员 如何一次性传输海量浮点数
@nagisaushio 弄好了,我现在就是这样,速度非常的快,40M 也是 1s 内的事情!大佬牛逼。
2025 年 5 月 13 日
回复了 iamtuzi3333 创建的主题 程序员 如何一次性传输海量浮点数
@ntedshen 解决了,直接用的二进制,前端根据字节数来解析,速度瞬间到达 1s 以内,谢谢大佬。
@nagisaushio 大佬牛逼,前端根据字节数直接读取数据就可以,现在传输就是 41M 左右!
2025 年 5 月 13 日
回复了 iamtuzi3333 创建的主题 程序员 如何一次性传输海量浮点数
都花在了传输上,数据大概 200 多 MB ,https://imgur.com/a/9BBQYIY
2025 年 5 月 13 日
回复了 iamtuzi3333 创建的主题 程序员 如何一次性传输海量浮点数
刚重新试了下,后端一秒就处理完成
https://imgur.com/a/l2aQxU3
前端从请求到接收用了 9 秒多
https://imgur.com/a/XOhxpnA
2025 年 5 月 13 日
回复了 iamtuzi3333 创建的主题 程序员 如何一次性传输海量浮点数
@ntedshen 前端处理是没问题,现在是传输过去很慢,花了十几秒
@nagisaushio 我现在是读取出来,再转为 json ,数据是从 dat 的二进制文件读取出来的,您说的我试试。
@dcsuibian 谢谢大佬,我就是发现直接打开连接就不行了,现在慢是先要读取文件,再把数据转为 json ,前端显示就是想做瀑布图,数据从头到尾 在一个框中从上到下流水一样,类似瀑布的效果,数据大小代表不同的颜色。
2025 年 5 月 13 日
回复了 iamtuzi3333 创建的主题 程序员 如何一次性传输海量浮点数
大佬们,现在用了一个 npz 打包,速度很快,我用的 Python ,代码如下:
@app.route('/get_data_bin', methods=['GET'])
def get_data_bin():
start = time.time()
data_2d, data_1d = readDataFile(r'C:\wxy\吕博士\data\data_2025-04-17 10-56-00_count2000_pointBytes20784.dat')

# 将两个数组打包成 .npz 压缩文件到内存
buf = io.BytesIO()
np.savez_compressed(buf, data=data_2d.astype(np.float32), timestamps=data_1d.astype(np.float64))
buf.seek(0)

print("打包耗时:", round(time.time() - start, 2), "秒")

return send_file(
buf,
as_attachment=True,
download_name="data.npz",
mimetype="application/octet-stream"
)
2025 年 5 月 13 日
回复了 iamtuzi3333 创建的主题 程序员 如何一次性传输海量浮点数
@dcsuibian 大佬,请教一下这里是怎么操作的,我用的 Python ,转的是 list 类型,list[list[float]]以及 list[float],这个传输量这么少的吗
2025 年 5 月 13 日
回复了 iamtuzi3333 创建的主题 程序员 如何一次性传输海量浮点数
@guiqiqi 明白,我试了再打包,没问题,就是前端解包挺麻烦
@lzxz1234 分布也试了,但是因为数据每十秒会变,这里多次分布请求担心出现不是同一批的数据
2025 年 5 月 13 日
回复了 iamtuzi3333 创建的主题 程序员 如何一次性传输海量浮点数
@ipwx 明白
@dcsuibian 是的,用了一个乘号,目前是 2000 行 5196 列的矩阵,另外一个是 2000 行一列。
@rekulas 现在卡的原因是前端提示接收不到这么多数据,我用页面请求 get 请求提示超出内存了,看了数据大概 210MB ,然后花了十几秒
这个三维的复杂的可以很复杂,简单的可以很简单,真的挺烦人,还是花钱交给专业的人干吧,现在很多领导都喜欢这种
深圳就这样,到处都是电动车,疯狂滴滴滴
2025 年 3 月 14 日
回复了 iamtuzi3333 创建的主题 职场话题 计算机环境真的比土木还坑
@RotkPPP 大佬,我没复习过申论,考的怎么样看运气吧,行测刷了一点题目,没想着一次能考上。
@CareFreeSc 没问题啊,主要能把颜色写的漂亮,页面酷
@Donahue 是啊,运气加选择大于实力,以前觉得努力可以改变,现在只想当咸鱼躺着给煎
2025 年 3 月 13 日
回复了 iamtuzi3333 创建的主题 职场话题 计算机环境真的比土木还坑
@tonytonychopper 也不用写很多啊,就写个用 echart 画了什么表格都比笼统的强
@noyidoit 很多是 ai 回复?
@d3js 985 待业表示环境差,985 都不好找
@make115 能上岸我就烧香拜佛了哈哈哈哈哈哈
2025 年 3 月 13 日
回复了 iamtuzi3333 创建的主题 职场话题 计算机环境真的比土木还坑
@tog 单独找个 ui 设计的好看我也搞不出页面。
@buf1024 单独搞一个美工我也搞不出页面来,而且现在就是想搞一个好看点的,然后换换颜色。
@129duckflew 这个是 ai 总结的吧,效果还可以,哈哈哈哈。
一下子这么多大佬出来说无病呻吟,标题党,真吓到了。我们是小公司,待遇还可以,压力也不会很强,所以找的人要求有点高,希望能有会点设计的前端大佬来帮忙,至于其他大佬说的看不懂就看不懂了,不重要;说到学历跟天花板这个,是看到环境太差了,需求少,人又多,35 岁又很明显;还是你们这些大牛厉害,不担心。
2025 年 2 月 28 日
回复了 xiaohupro 创建的主题 Redis Redis Stream 实现 MQ 的可行性
@suifengba 没并发吧,list 每秒队伍插入一条数据,然后每秒会自动取出 list 的所有数据,时不时就会出现跳过一条数据或者重复一条数据
2025 年 2 月 28 日
回复了 xiaohupro 创建的主题 Redis Redis Stream 实现 MQ 的可行性
@suifengba 我也用的这个,但是有一个 bug ,就是入队的时候速度很快,然后我 websocket 每秒轮询读取整个 list 数据,会出现偶尔跳过或者重复数据。
也一样,这个之前我关注了,内容也不好改动,我主要是后端,前端真不怎么会,还要好看,我还真的不行,醉了。
2025 年 2 月 24 日
回复了 iamtuzi3333 创建的主题 问与答 大佬们, 30TB 文件数据。有很多子目录,迁移请教
华为云竟然没有,提了工单说只能通过下载,带宽只有 30M ,这三十 T 下载到猴年马月啊,我真醉了
2025 年 2 月 24 日
回复了 iamtuzi3333 创建的主题 问与答 大佬们, 30TB 文件数据。有很多子目录,迁移请教
@stiangao 是的,但是华为云不知道有没有,我先提交个工单问问情况。
@Loyle5 那这样算下来速度也是很慢
1  2  3  4  5  6  7  8  9  10  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   5526 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 46ms · UTC 07:28 · PVG 15:28 · LAX 00:28 · JFK 03:28
♥ Do have faith in what you're doing.