Есть такое в .NET? Как избежать боксинга каждый раз когда нужно передать true/false туда, где параметр типа object?

Здравствуйте, AutumnLeaf, Вы писали:

AL>Есть такое в .NET? Как избежать боксинга каждый раз когда нужно передать true/false туда, где параметр типа object?

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

AL>Есть такое в .NET? Как избежать боксинга каждый раз когда нужно передать true/false туда, где параметр типа object?

Ну если реально критично, то можно сделать экстеншн-метод:

public static class MadHelper
{
    private static readonly object trueObj = true;
    private static readonly object falseObj = false;

    public static object bool Obj(this bool val)
        {
        return val ? trueObj : falseObj;
        }

    //если надо нуллабл
    public static object bool Obj(this bool? val)
        {
        return val.HasValue ? (val.Value ? trueObj : falseObj) : null;
        }
}

//ну и использовать как-то так:
var b = true;
b.Obj();
//или сразу
true.Obj();

Но на практике это надо специально изобретать тест, чтобы такое понадобилось.

Здравствуйте, AutumnLeaf, Вы писали:

AL>Есть такое в .NET? Как избежать боксинга каждый раз когда нужно передать true/false туда, где параметр типа object?

Стандартного нету. В WPF, например, своё сделали (см. BoleanBox или как-то так тип называется). Вот примерно это о чём: Tip: Improving Boolean Dependency Properties’ Performance

Здравствуйте, hi_octane, Вы писали:

_>Ну если реально критично, то можно сделать экстеншн-метод:

Если уж так загоняться на перфоманс, то:

    //если надо нуллабл
    public static object bool Obj(this bool? val)
        {
        return val.HasValue ? (val.GetValueOrDefault() ? trueObj : falseObj) : null;
        }

Действительно, на одну проверку меньше получается.

Здравствуйте, MozgC, Вы писали:

MC>Оверхед от боксинга будет порядка нескольких наносекунд, т.е. надо передать параметр хотя бы несколько сот миллионов раз, чтобы заметить этот оверхед. Оно вам точно нужно?

Так еще ведь оверхед по памяти и нагрузка на GC

Здравствуйте, hi_octane, Вы писали:

_>Ну если реально критично, то можно сделать экстеншн-метод:

_>Но на практике это надо специально изобретать тест, чтобы такое понадобилось.

Ну да, я тоже о таком подумал, но ожидал это увидеть в самой платформе...

Здравствуйте, AutumnLeaf, Вы писали:

AL>Так еще ведь оверхед по памяти и нагрузка на GC

Короткоживущие объекты не создают заметной нагрузки на GC. Ко времени очередной сборки большинство созданных короткоживущих объектов уже будут недостижимы для GC, он просто их не будет учитывать, пометит объекты, которые достижимы (т.е. на которые можно дойти по ссылкам начиная с корней), и дефрагментирует кучу.

Я вам не советую особо заморачиваться по поводу боксинга. Ну т.е. если его можно легко избежать — избегайте, а в противном случае — не забивайте голову, сконцентрируйтесь на бизнес-задачах. А о боксинге надо думать либо при разработке библиотек, либо когда он действительно является узким местом и влияет на перфоманс какого-то процесса.

Здравствуйте, MozgC, Вы писали:

MC>Короткоживущие объекты не создают заметной нагрузки на GC. Ко времени очередной сборки большинство созданных короткоживущих объектов уже будут недостижимы для GC, он просто их не будет учитывать, пометит объекты, которые достижимы (т.е. на которые можно дойти по ссылкам начиная с корней), и дефрагментирует кучу.

Хотя это так, но все же не выделение памяти 100%-но быстрее ее выделения. Смотри какие минимальные затраты создает выделение объектов:
1. Выделяемая память должна быть проинициализирована нулями. Это делается для больших блоков, потому не особо заметно на глаз, но все же время по любому тратится.
2. При создании объектов нужно обеспечить многопоточную безопасность. Даже если это всего один итрерлок, все равно это способно уменьшить производительность многопоточного приложения.
3. Рантайму нужно проинициализировать внутренние структуры объекта. Это нужно для GC и для того чтобы можно было получать инфотмацию о типах в рантайме.
4. При сборке мусора большое количество умерших объектов будет "разряжать" граф объектов, что приведет к увеличению промахов мимо кэша.
5. Распухание области отводимой под нулевое поколение GC приведет к более частым сборкам мусора.

Все это не так критично и при обычно этим можно пренебречь, но надо четко понимать, что не выделение памяти всегда быстрее ее выделения. Так что в критичных местах имеет смысл производить оптимизации вроде описанных в этой теме. Насколько я знаю в новом компиляторе Шарпа (из Розлина) во всю используются пулы объектов. Это делается именно в погоне за производительностью.