Yes, ideally code should not get slower with new releases – unfortunately, keeping track of performance regressions can be a bit of a game of whack-a-mole. Having examples of code whose speed has regressed is very helpful. Thanks to Jarrett Revels excellent work, we now have some great performance regression tracking infrastructure, but of course we always need more things to test!
On Mon, Feb 22, 2016 at 9:58 AM, Milan Bouchet-Valat <[email protected]> wrote: > Le lundi 22 février 2016 à 06:27 -0800, Jonathan Goldfarb a écrit : > > I've really been enjoying writing Julia code as a user, and following > > the language as it develops, but I have noticed that over time, > > previously fast code sometimes gets slower, and (impressively) > > previously slow code will sometimes get faster, with updates to the > > Julia codebase. > Code is not supposed to get slower with newer releases. If this > happens, please report the problem here or on GitHub (if possible with > a reproducible example). This will be very helpful to help avoiding > regressions. > > > No complaint here in general; I really appreciate the work all of the > > Core and package developers do, and variations in performance of > > different codes it to be expected. > > My question is this: has anyone in the Julia community thought about > > updated performance tips for writing high performance code? > > Obviously, using the profiler, along with many of the tips > > at https://github.com/JuliaLang/julia/commits/master/doc/manual/perfo > > rmance-tips.rst still apply, but I am wondering more about > > general/structural ideas to keep in mind in Julia v0.4, as well as > > guidance on how best to take advantage of recent changes on master. I > > know that document hasn't been stagnant in any sense, but relatively > > "big in any case, I'd be happy to help make some updates in a PR if > > there's anything we come up with. > I've just skimmed through this page, and I don't think any of the > advice given there is outdated. What's new in master is that anonymous > functions (and therefore map) are now fast, but that wasn't previously > mentioned in the tips as a performance issue anyway. > > The only small sentence which should likely be removed is "for example, > currently it’s not possible to infer the return type of an anonymous > function". Type inference seems to work fine now on master with > anonymous functions. I'll leave others confirm this. > > Anyway, do you have any specific points in mind? > > > Regards >
