windows 客户端 上传海量文件（5 万+），性能问题如何处理？

• 資深大佬 : crella

  百度网盘是有多个名为 baidunetdiskhost.exe 的后台进程。

  要不就新建一个不是 electron 的后台进程，这个进程负责计算 md5 和上传，然后指定协议与前台 electron 通讯。

  有时候百度网盘抽风，baidunetdiskhost 吃满单核 cpu，但是程序 ui 是没卡顿的。

• 資深大佬 : sc3263

  计算和上传的逻辑放到独立的子进程中去。
  或者写个 addon，在 addon 中新建线程进行处理。

• 主 資深大佬 : TomeWong

  @crella 我目前想到的是用 web worker 来分离计算 MD5 值，但效果不是很明显，文件数量多了，还是有问题。我先试试，谢谢大佬

• 主 資深大佬 : TomeWong

  @sc3263 electron 分主线程和渲染线程，我现在是将计算和上传的逻辑全部放在了渲染线程中

• 資深大佬 : nannanziyu

  密集型任务放到 Main 和 Render 里都不合适
  用 node-gyp 写到 c++里去

• 主 資深大佬 : TomeWong

  @nannanziyu 有相关的库或者类似么

• 資深大佬 : Mithril

  @TomeWong 不要放在同一个进程，文件 IO 也不要用多线程。

• 資深大佬 : g00001

  主进程 /渲染进程 – 这个是跨进程了，密集的跨进程通信效率不会很高。
  有些后台线程与界面的交互可能存在优化的空间，例如有时候过于密集的通知界面工作状态其实是无意义的。
  时间长就出问题，可能是存在内存泄露，JS 这种语言，太容易搞出内存泄露了。

  做这种事跟多线程开发利索的语言不能比。

• 主 資深大佬 : TomeWong

  @g00001 用 js 实现这种场景问题就很多

• 資深大佬 : sc3263

  @TomeWong Electron 应该是主进程和渲染进程吧，之间用 IPC 通讯。
  我们的客户端也是 Electron 实现的，计算 sha1 和上传都是放在 addon 里用 C 实现的。
  这种 CPU 密集任务还是不要为难 js 了。

• 資深大佬 : emeab

  放过 js 吧. 这些任务丢给 go 做不好吗? electron 做套壳吧

• 資深大佬 : xiangyuecn

  跟语言无关，写的太烂就算用 C 也不会快到哪去，v8 里面的 js 也并不慢，但你怎么可以把复杂运算任务丢到 UI 线程

• 資深大佬 : jones2000

  都做成客户端了，直接 c++开并行分块上传（ probuffer)， 计算 MD5 慢， 直接使用 GPU 计算， 页面只读取状态就可以了。

• 主 資深大佬 : TomeWong

  @xiangyuecn 刚开始用 Electron 开发，是新手，上传文件的多的话，就会出现问题

• 資深大佬 : xcstream

  子进程上传 传一个文件就关闭 就不会泄露什么

• 資深大佬 : magicdawn

  promise.retry 欢迎你. 加超时, 加重试.

  md5 node.js 里是同步的, 解决:
  主进程用 worker_threads, renderer 进程用 web worker

  P.S web worker 可以使用 node.js API, 但不能用 electron API & node native addon. see https://www.electronjs.org/docs/tutorial/multithreading#available-apis

• 資深大佬 : cheng6563

  @xiangyuecn 计算 md5 的开销很高的吧

• 資深大佬 : MintZX

  用的如果是云服务的话，直接让客户端上传到云服务里面，然后做一个 callback 到你的后端服务器就行了。

• 主 資深大佬 : TomeWong

  @cheng6563 小文件还好，大文件计算的时间会长些

• 主 資深大佬 : TomeWong

  @magicdawn 大佬，选择文件夹，这个文件夹包含大量的文件，这个过程会有计算 MD5 值，读文件流，如果是统一处理，然后再加入对列中，处理，中间会存在一部分空白响应等待的问题