blocks|key|4194900|text|这样做的问题是，导入仍然必须完成，然后才能使用。根据第一次使用它们的时间，应用程序可能仍然必须阻塞10秒，然后才能启动。更有效的方法是对模块进行概要分析，并找出它们为什么需要这么长时间才能导入。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4194901|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The problem with this is that the imports must still complete before they are usable. Depending on when they're first used, the application could still have to block for 10 seconds before it could start up anyway. Much more productive would be to profile the modules and figure out why they take so long to import.

blocks|key|413762|text|“用户使用GUI并开始新的物理模拟”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|413763|不是很清楚。“与GUI一起工作”是否意味着双击？双击什么？一些wxWidgets图形用户界面应用程序？还是闲置？|413764|如果是这样，“开始一个新的物理模拟”是什么意思？在其他地方点击按钮？一个GUI按钮，用来打开他们编写代码的面板？或者他们会导入他们离线编写的脚本吗？|413765|为什么导入会在模拟开始之前发生？模拟需要多长时间？GUI显示什么？|413766|我怀疑有一种方法可以在进行大型导入时变得懒惰得多。但从描述中，很难确定是否存在导入对用户不重要的时间点。|413767|线程不会有太多帮助。重新思考用户界面体验是有帮助的。|413768|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

"the user works with the GUI and starts a new physics simulation"

Not really clear. Does "works with the GUI" means double click? Double click what? Some wxWidgets GUI application? Or IDLE? 

If so, what does "starts a new physics simulation" mean? Click a button somewhere else? A GUI button to bring up a panel where they write code? Or do they import a script they wrote off line?

Why is the import happening before the simulation starts? How long does a simulation take? What does the GUI show?

I suspect that there's a way to be much, much lazier in doing the big imports. But from the description, it's hard to determine if there's a point in time where the import doesn't matter as much to the user.

Threads don't help much. What helps is rethinking the UI experience.

blocks|key|2729158|text|为什么不在应用程序启动时执行此操作？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2729159|def+background_imports():
++++import+Traits
++++import+Mayavi

thread+=+threading.Thread(target=background_imports)
thread.setDaemon(True)
thread.start()|code-block|syntax|javascript|2729160|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Why not just do this when the app starts?

<pre><code>def background_imports():
 import Traits
 import Mayavi

thread = threading.Thread(target=background_imports)
thread.setDaemon(True)
thread.start()
</code></pre>

blocks|key|800813|text|一般的想法是好的，但是当后台线程被锁定(import)时，Python/GUI会话可能不会有那么好的响应；不幸的是，import本质上不可避免地“锁定”了Python+(不仅仅是GIL，还有特定的额外的导入锁定)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|800814|尽管如此，仍然值得一试，因为这可能会让事情变得更好--这也非常简单，因为Queue本质上是线程安全的，而且除了Queue的put和get之外，您所需要的基本上只是一个__import__。|800815|如果您有一些本质上非常快的驱动器，但是空间有限，比如"RAM驱动器“或特别快的固态驱动器，那么可能值得将所需的包保存在.tar.bz2+(或其他形式的归档)中，并在程序启动时将其解压缩到快速驱动器(这本质上就是I/O，因此它不会严重锁定--+I/O操作会迅速释放GIL+--而且特别容易委托给运行tar+xjf或类似文件的子进程)。|800816|如果导入速度慢是由于大量的.py/.pyc/.pyo文件造成的，那么值得一试将这些文件(仅限于.pyc格式，而不是作为.py)保存在for文件中并从那里导入(但这只有助于I/O开销，这取决于您的操作系统、文件系统和驱动器:对于由于加载大量DLL或在加载时执行包中的初始化代码而导致的延迟，我怀疑这更可能是导致速度变慢的罪魁祸首)。|BOLD|800817|您还可以考虑使用multiprocessing拆分应用程序--同样使用队列(但属于多处理类型)进行通信--以便将导入和一些繁重的计算委托给几个辅助进程，从而使其成为异步的(这也有助于同时充分利用多个内核)。不幸的是，我怀疑这可能很难正确安排可视化任务(比如你可能正在用mayavi做的那些任务)，但如果你还有一些“纯粹的繁重计算”包和任务，它可能会有所帮助。|800818|entityMap^0|K|6|1M|6|0|10|5|1J|5|1P|3|1T|3|2B|A|0|1N|8|44|7|0|D|D|1B|4|1N|3|1I|3|0|8|F|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|16|8|@$9|17|A|18|B|C]|$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1B|8|@$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]|$9|1I|A|1J|B|L]]|D|@]|E|$]]|$1|M|3|N|5|6|7|1K|8|@$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1N|8|@]|D|@]|E|$]]]|P|$]]

The general idea is good, but the Python/GUI session might not be all that responsive while the background thread is <code>import</code>ing away; unfortunately, <code>import</code> inherently and inevitably "locks up" Python substantially (it's not just the GIL, there's specific extra locking for imports).

Still worth trying, as it might make things a bit better -- it's also very easy, since <code>Queue</code>s are intrinsically thread-safe and, besides a <code>Queue</code>'s <code>put</code> and <code>get</code>, all you need is basically an <code>__import__</code>. Still, don't be surprised if this doesn't help enough and you still need extra oomph.

If you have some drive that's intrinsically very fast, but with limited space, such as a "RAM drive" or a particularly snippy solid-state one, it may be worth keeping the needed packages in a <code>.tar.bz2</code> (or other form of archive) and unpacking it onto the fast drive at program start (that's essentially just I/O and so it won't lock things up badly -- I/O operations rapidly release the GIL -- and also it's especially easy to delegate to a subprocess running <code>tar xjf</code> or the like).

If some of the import slowness is due to a huge number of <code>.py/.pyc/.pyo</code> files, it's worth a try to keep those (in <code>.pyc</code> form only, not as <code>.py</code>) in a zipfile and importing from there (but that only helps with the I/O overhead, depending on your OS, filesystem, and drive: doesn't help with delays due to loading huge DLLs or executing initialization code in packages at load time, which I suspect are likelier culprits for the slowness).

You could also consider splitting the application up with <code>multiprocessing</code> -- again using Queues (but of the multiprocessing kind) to communicate -- so that both imports and some heavy computations are delegated to a few auxiliary processes and thus made asynchronous (this may also help fully exploiting multiple cores at once). I suspect this may unfortunately be hard to arrange properly for visualization tasks (such as those you're presumably doing with mayavi) but it might help if you also have some "pure heavy computation" packages and tasks.

I am writing a Python application in the field of scientific computing. Currently, when the user works with the GUI and starts a new physics simulation, the interpreter immediately imports several necessary modules for this simulation, such as <code>Traits</code> and <code>Mayavi</code>. These modules are heavy and take too long to import, and the user has to wait ~10 seconds before he can continue, which is bad.

I thought of something that might remedy this. I'll describe it and perhaps someone else has already implemented it, if so please give me a link. If not I might do it myself.

What I want is a separate thread that will import modules asynchronously. It will probably be a subclass of <code>threading.Thread</code>.

Here's a usage example:

<pre><code>importer_thread = ImporterThread()
importer_thread.start()

# ...

importer_thread.import('Mayavi')
importer_thread.import('Traits')
# A thread-safe method that will put the module name
# into a queue which the thread in an inifine loop

# ...

# When the user actually needs the modules:
import Mayavi, Traits
# If they were already loaded by importer_thread, we're good.
# If not, we'll just have to wait as usual.
</code></pre>

So do you know of anything like this? If not, do you have any suggestions about the design?

Python thread for pre-importing modules

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在编写一个科学计算领域的Python应用程序。目前，当用户使用图形用户界面并启动新的物理模拟时，解释器会立即导入此模拟所需的几个模块，如Traits和Mayavi。这些模块很重，而且导入时间太长，用户必须等待大约10秒才能继续，这是很糟糕的。我想到了一些可以弥补这个问题的方法。我将描述它，也许其他人已经实现了它，如...

问用于预导入模块的Python线程
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问用于预导入模块的Python线程EN