Sorry - it's part of a function: in_edges(g::AbstractGraph, v::Int) = [Edge(x,v) for x in badj(g,v)]
vs in_edges(g::AbstractGraph, v::Int) = map(x->Edge(x,v), badj(g,v)) On Wednesday, June 17, 2015 at 10:51:22 AM UTC-5, Mauro wrote: > > Note that inside a module is also global scope as each module has its > own global scope. Best move it into a function. M > > On Wed, 2015-06-17 at 17:22, Seth <[email protected] <javascript:>> > wrote: > > The speedups are both via the REPL (global scope?) and inside a module. > I > > did a code_native on both - results are > > here: https://gist.github.com/sbromberger/b5656189bcece492ffd9. > > > > > > > > On Wednesday, June 17, 2015 at 9:56:22 AM UTC-5, Stefan Karpinski wrote: > >> > >> I would have expected the comprehension to be faster. Is this in global > >> scope? If so you may want to try the speed comparison again where each > of > >> these occur in a function body and only depend on function arguments. > >> > >> On Tue, Jun 16, 2015 at 10:12 AM, Seth <[email protected] > >> <javascript:>> wrote: > >> > >>> I have been using list comprehensions of the form > >>> bar(g, a) = [Pair(x, g) for x in a] and [foo(x) for x in a] > >>> > >>> but recently evaluated bar(g, a) = map(x->Pair(x, g),a) and > >>> map(x->foo(x),a)as substitutes. > >>> > >>> It seems from some limited testing that map is slightly faster than > the > >>> list comprehension, but it's on the order of 3-4% so it may just be > noise. > >>> Allocations and gc time are roughly equal (380M allocations, ~27000MB, > ~6% > >>> gc). > >>> > >>> Should I prefer one approach over the other (and if so, why)? > >>> > >>> Thanks! > >>> > >> > >> > >
