I've seen the same. Looked away for a few weeks, and my code got ~5x slower. There's a lot going on so it's hard to say without detailed testing. However this code was always very sensitive to optimization to be able to specialize code which read data of different types. I got massive increases in memory allocations. I'll try to narrow it down, but it seems like perhaps something was done with optimization passes or type inference?
On Wednesday, June 10, 2015 at 9:31:59 AM UTC-4, Kevin Squire wrote: > > Short answer: no, poor performance across the board is not a known issue. > > Just curious, do you see these timing issues locally as well? In other > words, is it a problem with Julia, or a problem with Travis (the continuous > integration framework)? > > It might be the case that some changes in v0.4 have (possibly > inadvertantly) slowed down certain workflows compared with v0.3, whereas > others are unchanged or even faster. > > Could you run profiling and see what parts of the code are the slowest, > and then file issues for any slowdowns, with (preferably minimal) examples? > > Cheers, > Kevin > > On Wed, Jun 10, 2015 at 9:10 AM, andrew cooke <[email protected] > <javascript:>> wrote: > >> >> Is it the current poor performance / allocation a known issue? >> >> I don't know how long this has been going on, and searching for >> "performance" in issues gives a lot of hits, but I've been maintaining some >> old projects and noticed that timed tests are running significant;y slower >> with trunk than 0.3. CRC.jl was 40x slower - I ended up cancelling the >> Travis build, and assumed it was a weird glitch that would be fixed. But >> now I am seeing slowdowns with IntModN.jl too (factor more like 4x as slow). >> >> You can see this at https://travis-ci.org/andrewcooke/IntModN.jl >> (compare the timing results in the two jobs) and at >> https://travis-ci.org/andrewcooke/CRC.jl/builds/66140801 (i have been >> cancelling jobs there, so the examples aren't as complete). >> >> Andrew >> > >
