IronPython 2.6 медленнее, чем 2.0? - PullRequest
Новая
       13

IronPython 2.6 медленнее, чем 2.0?

2 голосов
/ 04 января 2010 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using IronPython;
using IronPython.Hosting;

namespace EmbeddedIP2_6
{
    class Program
    {
        static void Main(string[] args)
        {
            var engine = Python.CreateEngine();
            var ss = engine.CreateScriptSourceFromString("B", Microsoft.Scripting.SourceCodeKind.Expression);
            var cc = ss.Compile();
            var timer = System.Diagnostics.Stopwatch.StartNew();
            timer.Start();
            for (int i = 0; i < 10000; i++)
            {
                var scope = engine.CreateScope();
                scope.SetVariable("B", 2);
                var value = cc.Execute(scope);
            }
            timer.Stop();
            System.Console.WriteLine(timer.Elapsed.ToString());
        }
    }
}

Я пробую вышеупомянутое в C # 3.5, используя МПГ 2.0 и МПГ 2.6 Я считаю, что МПГ 2.6 медленнее, чем на порядок. Это, скорее всего, ошибка программиста. Любая помощь будет оценена.

Ответы [ 3 ]

2 голосов
/ 05 января 2010

В IronPython 2.6 DLR был обновлен для использования IDynamicMetaObjectProvider в качестве поддержки объектов области вместо устаревшего интерфейса IAttributesCollection. Это позволяет языкам реализовывать свой глобальный поиск таким образом, чтобы он также извлекал выгоду из кэширования сайтов вызовов. Например, вы можете представить себе веб-браузер с IDMOP, который имеет свойство «документ», чтобы языки могли быстро найти это часто используемое значение.

Вследствие этого, хотя все операции получения / набора проходят через ObjectOperations, которым необходимо получить связующее, получить или сделать сайт вызова, а затем выполнить вызов через сайт вызова. Это медленнее, чем то, что раньше вызывало интерфейс для поиска в словаре. Мы можем добавить несколько быстрых путей назад для общего случая, чтобы избежать накладных расходов на создание сайта вызова.

В долгосрочной перспективе вы сможете использовать динамическую C # для получения / установки значений в области, которая должна обеспечить вам наилучшую производительность.

0 голосов
/ 05 января 2010

Обходной путь для вышеуказанной проблемы: 

var scopeProvider = new Microsoft.Scripting.ScopeStorage();
scopeProvider.SetValue("B", true, 2);
var scope = engine.CreateScope(scopeProvider);

Это избавляет от снижения производительности при использовании предыдущего кода.

0 голосов
/ 04 января 2010

Вы делаете три вещи в цикле:

  • Создание области действия
  • Установка переменной в области действия
  • Выполнение сценария

В настоящее время вы не можете сказать, какие из них изменились с точки зрения производительности - возможно, все они.Я бы посоветовал вам изменить свой код, чтобы проверить это.

Кроме того, пробовали ли вы 2.6 в .NET 4.0?Мне было бы интересно услышать, каковы различия со встроенным DLR.Вполне возможно, нет никакой разницы, но ...

...