53
$\begingroup$

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}}

Improve this question
$\endgroup$
29
  • 4
    $\begingroup$ There will be a 10.0.1 not too long in the future, there's just too much problematic in M10. From what I hear through the grapevine, there should be a 10.0.1 not too far in the future. M10 has many performance problems of various types, and the cloud technology still has several shortcomings, and they know it. $\endgroup$
    – Andreas Lauschke
    Commented Aug 13, 2014 at 17:15
  • 12
    $\begingroup$ Reported as a slowdown problem. $\endgroup$
    – Daniel Lichtblau
    Commented Aug 13, 2014 at 18:30
  • 3
    $\begingroup$ Here is what I get under Win7 x64 after dividing timings from v.10.0.0 by the timings from v.8.0.4 obtained on the same machine: {{1.43073,1.45748,1.45371},{1.48448,1.47886,1.47511},{1.52418,1.53633,1.47204}}. So there is ~47% slowdown as compared to v.8. $\endgroup$
    – Alexey Popkov
    Commented Aug 13, 2014 at 18:33
  • 3
    $\begingroup$ Timings from v10 divided by timings from v7, under Windows: {{1.63,1.73,1.71}, {1.79,1.76,1.78}, {1.79,1.79,1.79}} $\endgroup$
    – Mr.Wizard
    Commented Aug 13, 2014 at 21:14
  • 4
    $\begingroup$ I get the following graph for the versions 5.0, 8.0.4, 9.0.1 and 10.0.1: i.sstatic.net/yTSU1.png $\endgroup$
    – halirutan ♦
    Commented Oct 7, 2014 at 4:58

2 Answers 2

Reset to default
12
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • 3
    $\begingroup$ Can you comment on "Like the kernel is slowed down due to the massive amount of new functions or packages?" please? Can this have a noticeable performance effect in a realistic situation? Can e.g. creating 1000 symbols, each with 5 associated definitions, have a performance impact on calculations not involving those specific symbols? (Even if this is not the cause of the specific slowdown that was being asked aboiut.) $\endgroup$
    – Szabolcs
    Commented Jul 11, 2018 at 7:48
6
$\begingroup$

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.

Improve this answer
$\endgroup$

Not the answer you're looking for? Browse other questions tagged or ask your own question.