ща, я уже в отладчике

ох там ад

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

а когда пишете вложенную функцию - можете быть уверенными, что он так делать не будет

но скорее всего он не может типы привести и специализировать код

я не понимаю. Типы все есть. Тип - это Array{String}. Если там есть что-то кроме этого, то где это найти?

компилятору главное - чтобы функция выдавала идентичный результат, так что я бы не полагался особо на println))

а это вообще ересь. Есть такая штука как сайд-эффекты, и их вообще никто не сможет соптимизировать.

(не имеет права)

есть черный ящик println, и ему должен быть передан правильно посчитанный аргумент

нашел статью, читайте после handling type-instability using function barriers

https://julialang.org/blog/2016/02/iteration

оттуда ссылаются на доки: https://docs.julialang.org/en/latest/manual/performance-tips/#kernel-functions-1

спасибо, щас посмотрю.

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

если тип поменяется, то зачем мы типизируем локальную переменную Array{String}? Она-то ведь жостко типизирована, и если придет не Array{String}, то должно ругнуться на рантайме во время convert (неявного).

если написано

a :: Array{String} = ...
for i in 1::length(a) if a[i]=="B" then end end

этот код полностью типизирован, и результирующий код может быть только один и только один.

(это то что я полагаю сейчас)

в статье про function barrierс там все ясно. Там основная функция получает нетипизированные переменные и не может специализироваться так, как функция которая делает собственно loop. Функция которая делает loop, специализируется по типу массива. Потому что тип массива становится известен ДО того как сделается кодеген на цикл. Там динамик диспатч по типам на экземпляр функции с конкретным массивом (там отличается у них мерность массива например). У нас только 1 тип, этот тип Array{String} и он известен и неизменен всегда. У нас другой случай. Тот факт, что это лечится через function barrier (wtf3) говорит о том, что кодеген генерирует разный (?) код для случая когда тип указан в локальной переменной и когда тип указан в аргументе функции (в любом случае типов достаточно).

Если это так, то это заставляет меня скорбеть, потому что почему?

Задайте вопрос здесь: discourse.julialang.org

я задам, обязательно, если не найду свой ответ. Спасибо.