а что вот это дает <'b when 'b :> IComparable>

бокс убрал

У тебя было match box

У тебя было match box

это оптимайзится

а ты все равно бокс добавил потому что это явный интерфейс

охуенный ты оптимизатор

а ты все равно бокс добавил потому что это явный интерфейс

И он не заоптимайзится?

И он не заоптимайзится?

ниибу

Ну щас сравним

я только знаю что match box generic with | :? valueType as v ->

оптимайзится

жидом, а не компилятором

тайная магия

чот хуита какая-то

инлайн не помог

Щас сравню с боксом

Код бенчмарков бы еще.

``` // Learn more about F# at http://fsharp.org open System open System.Collections.Generic open BenchmarkDotNet.Attributes open BenchmarkDotNet.Running module Comparer = let inline getNext<'b> (someEnum: IEnumerator<IComparable>): 'b voption = let mutable result = ValueNone let mutable notFound = true while notFound && someEnum.MoveNext() do match box someEnum.Current with | :? 'b as x -> notFound <- false result <- ValueSome x | _ -> () result let compare (a: IComparable seq) (b: IComparable seq): bool = use aEnum = a.GetEnumerator() use bEnum = b.GetEnumerator() let mutable aNext = ValueNone let mutable bNext = ValueNone let mutable isEqual = true let mutable notFinished = true while isEqual && notFinished do aNext <- getNext<int> aEnum bNext <- getNext<int> bEnum match aNext, bNext with | ValueSome _, ValueNone | ValueNone, ValueSome _ -> isEqual <- false | ValueSome ai, ValueSome bi when ai <> bi -> isEqual <- false | ValueNone, ValueNone -> notFinished <- false | ValueSome _, ValueSome _ -> () isEqual let compareBuilder (a: IComparable seq) (b: IComparable seq) = let inline seq (items: IComparable seq) = seq { for item in items do match item with | :? int -> yield item | _ -> () } (Seq.compareWith Operators.compare (seq a) (seq b)) = 0 [<MemoryDiagnoser>] type Bench() = let a = [| for i in 0 .. 100_000 do yield i :> IComparable |] let b = [| for i in 0 .. 100_000 do yield i :> IComparable |] [<Benchmark>] member x.Ayrat() = Comparer.compare a b [<Benchmark>] member x.Builder() = Comparer.compareBuilder a b // [<Benchmark>] // member x.Equals() = a = b [<EntryPoint>] let main argv = let summary = BenchmarkRunner.Run<Bench>() 0 // return an integer exit code```

вот да, я б погонял профайлером.

Мб секбилдер как-то массивы оптимизирует, хз

Хотя с памятью вообще дичь какая-то

А, я знаю что срёт

match aNext, bNext with

Это ж в туплю сворачивается?

match struct(aNext, bNext) with

чот хуита какая-то

С боксом медленнее, кстати

да тут как бы надо понять откуда 3мб

Щас матчстракт попробую

@Dolfik Правильно данные для тестов готовишь?

@Dolfik Правильно данные для тестов готовишь?

А что не так?

В какой момент создаются массивы?

В какой момент создаются массивы?

В конструкторе

ок, это туплы

Они для всех бэнчей одинаково

ебаный матч на туплях

ЩА ОПТИМИЗНЕМ

ЩА ОПТИМИЗНЕМ

Ща померяем на стракт туплях

несложно было узнать

:D

А Я ГОВОРИЛ!

ну я честно говоря думал что компилятор умнее

потому что тут тупль создается и деструктится ТУТ ЖЕ

не вижу ни одной причины почему эта хуита должна через хип ходить

потому что тут тупль создается и деструктится ТУТ ЖЕ

Да самое забавное, что он в таких кейсах сам типы умеет выводить

Да самое забавное, что он в таких кейсах сам типы умеет выводить

причем это должно быть прозрачно для тебя, в коде ты пишешь обычный тупль match a, b, c with | x, y, z -> это не должно ходить через хип

БАЙДИЗАЙН

причем это должно быть прозрачно для тебя, в коде ты пишешь обычный тупль match a, b, c with | x, y, z -> это не должно ходить через хип

Так же как и let a, b = if a.Length > b.Length then a, b else b, a

Настроечку бы компилятору

Чтобы такое оптимизил

Так же как и let a, b = if a.Length > b.Length then a, b else b, a

ну короче тут можно через структ тупли, можно ручными ифами

Настроечку бы компилятору

Мб попробовать толкнуть?

Мб попробовать толкнуть?

@gsomix он точно знает, толкал ли кто-то такое

причем это должно быть прозрачно для тебя, в коде ты пишешь обычный тупль match a, b, c with | x, y, z -> это не должно ходить через хип

@vl_za это можно починить?

@vl_za это можно починить?

Ну вряд-ли конечно будут breaking changes делать, но вот хотя бы настройку

Ну вряд-ли конечно будут breaking changes делать, но вот хотя бы настройку

не, это локальная оптимизация для структов которые анонимно создаются и тут же деструктятся

то есть они даже не биндятся никуда

не, это локальная оптимизация для структов которые анонимно создаются и тут же деструктятся

А, хотя да

@vl_za это можно починить?

Ща, найду откуда начинать читать

Не возвращаются же

@gsomix он точно знает, толкал ли кто-то такое

Выглядит очень странно.

Ща, найду откуда начинать читать

тупли в матче ходят через хип match a, b, c with | x, y, z -> хотя тут тупль создается и деструктится по месту

он никуда не утекает

компилятор знает что он никуда не утекает?

компилятор знает что он никуда не утекает?

Должен в общем случае, да.

если знает, пусть эмитит валуетуполь

компилятор знает что он никуда не утекает?

Нужно минимальный пример составить.

на ровном месте 3мб аллокаций!!1 @vl_za

Вот, а вы говорили хуйней занимаюсь!

на ровном месте 3мб аллокаций!!1 @vl_za

Чтобы не расслаблялись

Нужно минимальный пример составить.

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

Чтобы не расслаблялись

Чтобы в ченжлоге писать: memory usage optimizations

на ровном месте 3мб аллокаций!!1 @vl_za

На завтра напоминалку поставил, гляну, ща уже не за ноутом

На завтра напоминалку поставил, гляну, ща уже не за ноутом

Спасибо добрый человек

Нужно минимальный пример составить.

Кортеж остается в присутствии mutable.

Кортеж остается в присутствии mutable.

поясни

поясни

https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AbEAzAzgHwxgBcACbCCYAQylIAoBKUgXgFgAoU70osgWwCuxasCKlqrUgDVqGQTADKEfjFIoATJx68SpISLFrgU2fJgA5CADsY2nv2rEwACwlpSJgO4BLYi/tufBk5BWVVUgB9DzMFK1tSOAA+BkZA0mDIxJSmIA==

Если убрать mutable, то компилятор сможет оптимизировать match.