What about an optimized map() version that either accepts a type as
parameter for the resulting collection, or decides the type of the
resulting collection based on the first result? Or maybe both?
On Sunday, December 29, 2013 7:15:36 PM UTC+1, Stefan Karpinski wrote:
>
> 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
>>>
>>>
