On Fri, Aug 14, 2015 at 12:25 PM, Joseph L. Casale
wrote:
> Yeah that wasn't clear. The plugins are invoked in fresh interpreter processes
> and hence modules with import side effects or simply large modules can
> manifest over time.
If they're invoked in fresh processes, then you're looking at p
> Importing is not the same as instantiation.
>
> When you import a module, the code is only read from disk and instantiated
> the first time. Then it is cached. Subsequent imports in the same Python
> session use the cached version.
I do mean imported, in the original design there were many ctype
On Fri, 14 Aug 2015 07:12 am, Joseph L. Casale wrote:
>> What makes you think the import might be a problem? That's a one-time
>> thing. Or is your application a command-line tool or so that needs to
>> start and terminate quickly?
>
> The code is used within plugin points and soon to be asynchro
Hi Stefan,
> How is the DLL binding implemented? Using "ctypes"? Or something else?
It is through ctypes.
> Obviously, instantiating a large ctypes wrapper will take some time. A
> binary module would certainly be quicker here, both in terms of import time
> and execution time. Since you're gene
Joseph L. Casale schrieb am 13.08.2015 um 18:56:
> I have an auto generated module that provides functions exported from a
> c dll. Its rather large and we are considering some dynamic code generation
> and caching, however before I embark on that I want to test import times.
>
> As the module is
I have an auto generated module that provides functions exported from a
c dll. Its rather large and we are considering some dynamic code generation
and caching, however before I embark on that I want to test import times.
As the module is all auto generated through XSL, things like __all__ are not
