Yes, that 33 seconds for the first Gadfly plot is all code generation – the second time you do it, it certainly doesn't take 33 seconds.
On Mon, Feb 23, 2015 at 1:34 PM, Tim Holy <[email protected]> wrote: > Do those timings include compilation? It's not really meaningful on the > first > run. > > For reference: on my laptop, Winston (on the second run): > > julia> @time (p = plot(x,y); display(p)) > elapsed time: 0.256627468 seconds (16 MB allocated, 1.77% gc time in 1 > pauses > with 0 full sweep) > "" > > Even this is slow by comparison to where I think we want to be. > > --Tim > > On Monday, February 23, 2015 06:27:24 PM Samuel Colvin wrote: > > You're probably right about research publications, I guess plots these > > don't need to be interactive which makes things easier from a cross > > platform perspective. > > > > Performance wise I'm not sure you're right, with Julia 0.3.6 and latest > > packages: > > > > julia> using Gadfly > > > > julia> x=1:1000000 > > 1:1000000 > > > > julia> y=sqrt(x); > > > > julia> @time draw(PNG("test.png", 6inch, 3inch), plot(x=x, y=y)) > > elapsed time: 33.860814218 seconds (2043746808 bytes allocated, 3.83% gc > > time) > > > > julia> import Bokeh > > > > julia> Bokeh.autoopen(true) > > true > > > > julia> @time Bokeh.plot(x, y) > > elapsed time: 1.557460583 seconds (125617712 bytes allocated) > > Plot("Bokeh Plot" with 1 datacolumns) > > > > Timing on my phone, the Bokeh plot had opened in chrome in 6 seconds. It > > was a little slow but still fine to zoom/pan etc. > > > > One of the nice things about Bokeh is that unlike d3, plotly or Gadfly it > > uses canvas not SVG for it's plots which makes it way faster. > > > > > > -- > > > > Samuel Colvin > > [email protected], > > 07801160713 > > > > On 23 February 2015 at 18:00, Stefan Karpinski <[email protected]> > wrote: > > > Bokeh and Bokeh.jl are both very cool – thanks so much for all the > work on > > > the package! > > > > > > There seem to still be visualization tasks that have scale and > performance > > > requirements such that HTML and JavaScript don't cut it. Web > technologies > > > are also generally not up to the task of producing publication-quality > > > graphics, e.g. for research publications. The gaps are probably both > > > diminishing, but I don't think we're quite there yet. > > > > > > On Mon, Feb 23, 2015 at 12:38 PM, Samuel Colvin <[email protected]> > > > > > > wrote: > > >> To coincide (approximately) with the release of Bokeh v0.8.0 I've > > >> released a significantly improved version of Bokeh.jl: > > >> > > >> http://bokeh.github.io/Bokeh.jl/ > > >> > > >> This is the first plotting library I've built and the first proper > Julia > > >> package. I would therefore really appreciate any feedback on the > plotting > > >> interface and the structure of the package itself. > > >> > > >> Bokeh.jl is still a bit rough round the edges and missing some basic > > >> features, but the examples above demonstrate what it can do. > > >> > > >> Bokeh <http://bokeh.pydata.org/en/latest/> is an interactive plotting > > >> library originally developed for python which uses HTML & Javascript > as > > >> it's backend to display and manipulate plots. > > >> > > >> Whether by using Bokeh or other libraries, web technologies are the > > >> obvious option for Julia to get great visualization/graphics/UI > without > > >> the > > >> pain. > > >> > > >> I suggest (and I assume I'm about to get shot down) that the Julia > > >> community stops messing around with any OS specific graphics code and > > >> adopts HTML for all future visualizations. Are there any cases where > that > > >> wouldn't work? > >
