今天小编给大家分享一下Python如何解压zip文件的相关知识点，内容详细，逻辑清晰，相信大部分人都还太了解这方面的知识，所以分享这篇文章给大家参考一下，希望大家阅读完这篇文章后有所收获，下面我们一起来了解一下吧。首先是下面这些模拟对 zip 文件中文件实际操作的普通函数：这里是可能最简单的另一个函数：如果我更仔细地分析一下，我将会发现这个函数花费时间 40% 运行extractall，60% 的时间在遍历各个文件并读取其长度。我的***步尝试是使用线程。先创建一个zipfile.ZipFile的实例，展开其中的每个文件名，然后为每一个文件开始一个线程。每个线程都给它一个函数来做“实质工作”（在这个基准测试中，就是遍历每个文件然后获取它的名称）。实际业务中的函数进行的工作是复杂的 S3、Redis 和 PostgreSQL 操作，但是在我的基准测试中我只需要制作一个可以找出文件长度的函数就好了。线程池函数：结果：加速 ~10%所以可能是 GIL（LCTT 译注：Global Interpreter Lock，一种全局锁，CPython 中的一个概念）阻碍了我。最自然的想法是尝试使用多线程在多个 CPU 上分配工作。但是这样做有缺点，那就是你不能传递一个非可 pickle 序列化的对象（LCTT 译注：意为只有可 pickle 序列化的对象可以被传递），所以你只能发送文件名到之后的函数中：结果: 加速 ~300%使用处理器池的问题是这样需要存储在磁盘上的原始.zip文件。所以为了在我的 web 服务器上使用这个解决方案，我首先得要将内存中的 zip 文件保存到磁盘，然后调用这个函数。这样做的代价我不是很清楚但是应该不低。好吧，再翻翻看又没有损失。可能，解压过程加速到足以弥补这样做的损失 香港云主机了吧。但是一定记住！这个优化取决于使用所有可用的 CPU。如果一些其它的 CPU 需要执行在gunicorn中的其它事务呢？这时，这些其它进程必须等待，直到有 CPU 可用。由于在这个服务器上有其他的事务正在进行，我不是很确定我想要在进程中接管所有其他 CPU。一步一步地做这个任务的这个过程感觉挺好的。你被限制在一个 CPU 上但是表现仍然特别好。同样地，一定要看看在f1和f2两段代码之间的不同之处！利用concurrent.futures池类你可以获取到允许使用的 CPU 的个数，但是这样做同样给人感觉不是很好。如果你在虚拟环境中获取的个数是错的呢？或者可用的个数太低以致无法从负载分配获取好处并且现在你仅仅是为了移动负载而支付营运开支呢？我将会继续使用zipfile.ZipFile(file_buffer).extractall(temp_dir)。这个工作这样做已经足够好了。我使用一个c5.4xlargeEC2 服务器来进行我的基准测试。文件可以从此处下载：这里的.zip文件有 34MB。和在服务器上的相比已经小了很多。以上就是“Python如何解压zip文件”这篇文章的所有内容，感谢各位的阅读！相信大家阅读完这篇文章都有很大的收获，小编每天都会为大家更新不同的知识，如果还想学习更多的知识，请关注开发云行业资讯频道。
相关推荐: SOFAJRaft | SOFAChannel#8 的示例分析
本篇文章为大家展示了SOFAJRaft | SOFAChannel#8 的示例分析，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。Raft 是一种共识算法，其特点是让多个参与者针对某一件事达成完全一致：一件事，一个结论。…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
