Ouch, it looks like it does even after code generation. I need to look into 
that. I never noticed because I always use hexbin for these sorts of plots, 
which also could be faster but is still only 2.5 seconds for this example.

On Monday, February 23, 2015 at 10:36:28 AM UTC-8, Stefan Karpinski wrote:
>
> 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] <javascript:>
> > 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] 
>> <javascript:>> 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] 
>> <javascript:>>
>> > >
>> > > 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?
>>
>>
>

Reply via email to