You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From profiling psyneulink code, I found that parameter.__getattr__ was called many times.
For example, in the following code: from psyneulink.core.components import component
There were about 300,000 calls to parameter.__getattr__.
In addition, creating components in psyneulink seems to also increase the number of calls to parameter.__getattr__, up to the order of millions of calls.
Testing shows that these calls represent atleast 40% (if not more) of the total time spent when creating nodes and importing psyneulink.
These counts seem a bit excessive; I'm wondering if there may be a bug buried deep in the parameters class - or potential for significant optimization.
The text was updated successfully, but these errors were encountered:
As discussed in today's meeting, it may be beneficial to refactor the parameter class in its entirety, so that it exists as essentially a wrapper around ctype objects.
This could potentially be more efficient, and also has the added benefit of solving synchronization between compiled psyneulink and python psyneulink.
From profiling psyneulink code, I found that
parameter.__getattr__
was called many times.For example, in the following code:
from psyneulink.core.components import component
There were about 300,000 calls to
parameter.__getattr__
.In addition, creating components in psyneulink seems to also increase the number of calls to
parameter.__getattr__
, up to the order of millions of calls.Testing shows that these calls represent atleast 40% (if not more) of the total time spent when creating nodes and importing psyneulink.
These counts seem a bit excessive; I'm wondering if there may be a bug buried deep in the
parameters
class - or potential for significant optimization.The text was updated successfully, but these errors were encountered: