These are all problems. They will hopefully be fixed but they're pretty
tricky to deal with. Map + typed collections + dynamic typing is a bit
problematic. May take some inventiveness to improve significantly.
On Sunday, December 29, 2013, Ivar Nesje wrote:
> Another (currently, I think) bad thing about map, is that there (for fast
> functions) is a significant overhead because you call a (anonymous)
> function from a variable. I do not think that map gets compiled
> specifically for the specific function you pass to it, so that the correct
> method needs to be picked at runtime, not at compile time as would happen
> for a list comprehension or a explicit loop.
>
> Ivar
>
> kl. 18:03:29 UTC+1 søndag 29. desember 2013 skrev John Myles White
> følgende:
>>
>> Errrr, make that the type of the output. map often produces Array{Any}
>> when you wanted something like Array{Float64}.
>>
>> — John
>>
>> On Dec 29, 2013, at 11:58 AM, andrew cooke <[email protected]> wrote:
>>
>> > From the comment at https://gist.github.com/nalimilan/8132114
>> > (am I reading it wrong, does it just mean map with local anon
>> functions?)
>> >
>> > Is it the overhead of creating an intermediate Task? Are there any
>> plans to merge nested tasks as an optimisation (I have no idea if something
>> like that is even possible)? Or to replace the "collect(map(...))" idiom
>> with something faster?
>> >
>> > Thanks,
>> > Andrew
>>
>>
