Yes, that's the performance tip I meant. Thanks for your detailed response and reference to the issue; that sounds like a good way forward. I'll be looking forward to future developments Regards, -Max
> On Feb 28, 2016, at 7:26 PM, Yichao Yu <[email protected]> wrote: > > On Sun, Feb 28, 2016 at 7:24 PM, Yichao Yu <[email protected]> wrote: >> On Sun, Feb 28, 2016 at 6:49 PM, Jonathan Goldfarb <[email protected]> >> wrote: >>> I realize now I may have been misunderstanding >>> http://docs.julialang.org/en/release-0.4/manual/performance-tips/#avoid-containers-with-abstract-type-parameters > > Also note that the reference that's more related to your confusion is > http://docs.julialang.org/en/release-0.4/manual/performance-tips/#declare-specific-types-for-fields-of-composite-types > >>> for a long time... Is the recommendation there only related to parameterized >>> types, or any user defined type? My specific question, in the latter case, >>> is the following >> >> It's about typed slot (i.e. container) in general and has nothing to >> do with type parameters. using a `TypeA{AbstractType}` won't cause any >> performance problem as long as you are not using the `AbstractType` as >> one of the field type. OTOH, having a abstract type field will cause >> any use of the field to be type unstable, no matter whether the type >> is parametrized or not. >> >>> >>> Since Function is an abstract type after >>> https://github.com/JuliaLang/julia/pull/13412#issuecomment-175200009 what is >> >> The `Function` type is special in the sense that it is always >> "abstract" since it never has the information for type inference when >> you want to call the function. (If you are just passing functions >> around without calling it then yes, `Function` was a leaftype and was >> type stable) >> >>> the recommended way to have e.g. >>> immutable J >>> a::Function >>> b::Function >>> end >> >> If you want to specialized on the actual function called, use >> >> ``` >> immutable J{F1,F2} >> a::F1 >> b::F2 >> end >> ``` >> >> Otherwise, keeping it like this shouldn't cause any performance issue >> compare to 0.3 and 0.4 due to the reason mentioned above. >> >>> be used in a performant way? Evidently, we should not form e.g. an >>> Array{Function, 1}, but would using types like this in code give similarly >>> poor performance? >> >> See also my summary in https://github.com/JuliaLang/julia/issues/13984 >> >>> >>> Thanks, >>> Max
