[Ironpython-users] IronPython, Daily Digest 4/10/2012

[no_reply at codeplex.com]

Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] ScriptScope.ContainsVariable throws MissingMemberException internally
2. [New comment] ScriptScope.ContainsVariable throws MissingMemberException internally
3. [New comment] ScriptScope.ContainsVariable throws MissingMemberException internally

----------------------------------------------

ISSUES

1. [New comment] ScriptScope.ContainsVariable throws MissingMemberException internally
http://ironpython.codeplex.com/workitem/32530
User rumzeus has commented on the issue:

"Thanks for the workaround with "GetVariableNames().Contains(name)"! Does anyone know if there's a performance penalty with this approach?

The same problem also exists for ScriptScope.TryGetVariable(). I'm considering using "if(scope.GetVariableNames().Contains(name)) scope.GetVariable(name)" instead.

It would of course still be great if this could be fixed in ScriptScope.Contains() and ScriptScope.TryGetVariable() itself."-----------------

2. [New comment] ScriptScope.ContainsVariable throws MissingMemberException internally
http://ironpython.codeplex.com/workitem/32530
User rumzeus has commented on the issue:

"I just quickly tested the performance of scope.ContainsVariable() (CV) vs. scope.GetVariableNames().Contains() (GVC) in my use case:
Result | 	GVC Average 	 | CV Average 	 | GVC StdDev	 | CV StdDev
true	| 	0.013863441	 | 0.002355914	 | 0.007359396	 | 0.001139271
false | 	0.120864103	 | 33.03118077	 | 0.882787111	 | 1.135868631

So scope.ContainsVariable() was ~5.8 times faster if the result is true, but ~273 times slower if the result is false.

(Disclaimer: Probably not a very accurate or representative test.)"-----------------

3. [New comment] ScriptScope.ContainsVariable throws MissingMemberException internally
http://ironpython.codeplex.com/workitem/32530
User KeithJRome has commented on the issue:

"For your test, I presume you tried accessing the same variable repeatedly in a loop? CallSite caching might be coming into play. Depending on your actual situation, that might either support or invalidate the test.

For CV, the runtime is setting up an exception frame, looking to see if a callsite is cached for the expected member / signature, and if so then it returns true (fast case). If not, then it attempts to create and cache the callsite and throws the exception if that fails (slow case). The first access of any member should be very slow, but subsequent accesses should be much quicker.

I presumed GVC was simply returning the Keys of an internal dictionary, which I would have expected to perform better in all cases. In looking deeper at the implementation, GVC actually doesn't do that exactly. It too routes through a callsite (however, a callsite that is always going to succeed) to reach GetMemberNames on the internal ScopeStorage container.

I don't really see a clean way to optimize it since _storage on Scope is dynamic and has several possible concrete implementations in Microsoft.Scripting.

So your best bet is to use CV if you expect the variable to be there the vast majority of the time, but use GCV if the chances of it not being there are high, or if you just need to be conservative. If the object's name table is stable then you could hold on to the GVN results instead of requerying each time, which should yield the best performance."
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20120411/3a489edf/attachment.html>