Slow ApplicationSettingsBase

Question

Механизм настройки приложения (производный от ApplicationSettingsBase) кажется реальным узким местом при использовании в многопоточных сценариях. Особенно, когда свойства часто запрашиваются, параллелизм, который они вводят, замедляет мои циклы. В любом случае, мне нравится использовать их, чтобы иметь хороший вариант конфигурации приложения. Но, может быть, мне нужно обернуть их в свой кеш или около того?

У кого-нибудь есть такая же проблема? Я что-то пропустил? Я думал, ApplicationSettingsBase уже кеширует все настройки? Почему он вообще блокирует доступ из нескольких потоков? Что может быть общим обходным путем?

Answer 1

Я не вижу ничего странного в том, что у вас есть механизм настройки потоков? Если это замедляет ваши одновременные игры, вы должны попытаться использовать локальные переменные вместо того, чтобы снова быстро запросить getsetting. Я думаю, что редизайн вашего механизма запроса настроек значительно улучшит производительность.

Answer 2

Я бы действительно предложил обернуть любую функцию «получить настройки» в объект и спрятать его за интерфейсом. Мы строго набираем это, поэтому имеем:

public class Worker 
{
    private readonly ISettings settings;
    public Worker (ISettings settings)
    {
        this.settings = settings;
    }

    public void Work ()
    {
        for (int i = 0; i < settings.MaxWorkerIterations (); i++)
        { ... }
    }
}

public interface ISettings
{
    int MaxWorkerIterations ();
}

public class AppConfigSettings
{
    public int MaxWorkerIterations ()
    {
        return (int) ApplicationSettings["MaxWorkerIterations"];
    }
}

Это имеет преимущество (в основном) проверки во время компиляции и легкой тестируемости. Вы также можете переопределить свой класс AppConfigSettings, чтобы он стал классом CachingAppConfigSettings, который делает очевидное.