Is this 30% slowdown in Mathematica 10 due to DownValues lookup time?

Question

Running several numerical self-programmed packages I realized already some time ago that Mathematica 10 needed between 20 and 40% more time. I did already report this of course with a simple example to Wolfram support, but have somehow not got any official response. Investigating a bit more I would like to ask with this specific example (which seems to be even more terrifying under Linux, don't know MacOSX) why this slowdown happens.

Is it maybe the DownValues lookup time?

Is there some other reason? Like the kernel is slowed down due to the massive amount of new functions or packages? Or nobody cares anymore about performance for user-programs longer than one line? Or should we cloud-less users all just wait for a better Mathematica 10.0.1 release?

This

   zeit[dval_, m_] := 
      With[{dv = dval, n = m}, 
       Block[{f}, 
             Do[f[i, x_] := x*i, 
                {i, dv}
             ]; 
             First[
                Timing[
                     Table[f[i, 42], {i, dv}, {n}]]]]
     ];
    Timing[checkit = Table[ zeit[dv, n], 
                            {dv, 200, 600, 200}, 
                            { n, 200, 600, 200}]; ]

runs about 35 % slower in Mathematica 10.0.0 on Windows 8.1 compared to Mathematica 9.0.1 on the same computer.

Dividing the values for checkit in V10 by the values from V9 gives for me approximately:

{{1.29, 1.39, 1.36}, {1.36, 1.33, 1.35}, {1.38, 1.36, 1.35}}

What timings do others get?

---

Edit:

Still the case in V10.0.2 ...

Edit:

Fixed in 10.1.0, which is now even faster (tested on Windows)! Great, WRI!

Linux: 10.1 slightly faster than 9.0.1: {{1., 0.97, 1.}, {0.97, 0.98, 1.}, {0.98, 0.98, 0.99}}

Answer 1

I realize this answer comes about three years too late, but having come accross the question, here's an answer.

The general slowdown that was fixed in 10.1, and that hit Linux particularly hard, was due to a change a compilation settings to enable the kernel to be loaded as a library and not just run as a program. This had implications for function calls across different compilation units that wasn't fully understood, and the 10.0 version had significant overhead as a result. This was fixed by additional tweaks so that functions between different compilation units could be called with minimal overhead.

I'm not aware of any other big slowdown in 10.0, or indeed in any release since (obviously certain specific functions had bugs that caused them to be slow). As always, performance can vary as we updated external libariries, compilers, etc. If you have a reproducible slowdown, your best recourse is to contact support with your example so we can evaluate it.

Update: additional symbols causing slowdown?

Since I was asked to comment on the addition of symbols as a possible slowdown, the short answer is that it is theoretically possible, but it is unlikely to be the cause of any general slowdown in the product.

Adding DownValues to a symbol can't slowdown the evaluation of other symbols. It will only affect the evaluation of that symbol.

Adding UpValues is a potential source of slowdown, since anywhere the symbol to which the UpValue is attached you need to determine if the UpValue fires. However, there are a number of optimizations in place to ensure that cost of the scan is negligible, and the UpValue pattern only needs to be tested if both symbols are present.

Having a huge number of symbols (say, hundreds of thousands) spread across of a large number (say, tens of thousands) of contexts can cause a measurable slowdown in symbol lookup. However, we're not close to that. Even in 11.3, I see 546 contexts at startup, growing to a little over 1000 as I use different functions. For comparison, V9 had 361 contexts at startup. It's definitely grown, but not by a scale that's worrisome.

What is true is that as we have more symbols spread across more packages, then there are potentially slow initial evaluations as the packages get loaded. But that would be a one-time cost per package.

Answer 2

This specific slowdown is solved in Mathematica 10.1. Probably it was not just DownValues but something else. Anyway. Other slowdown's are still there, unfortunately, but they are harder to pin down. So at least this artificial example is solved.