Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I run Mathematica v9 on my Atom laptop (don't ask) and I got used to the fact that everything is slower. Except for one annoying thing: cursor movement (in text) is slower than the keyboard key repeat rate. In other editors I am used to hold down the up/down/left/right keys and I expect the cursor to stop when I release the key. In Mathematica Frontend this is not the case, keyboard buffer gets filled with keyboard events which get executed by the Frontend way later than the release of the key. This annoying behavior trained me to use only single presses of the movement keys (or mouse clicks at the right position). You can imagine, scrolling through a lot of code in this way can be quite painful.

What is even more interesting is that the speed with which Frontend executes the cursor movements depends on the overall size of the notebook file and the current relative position of the cursor the file. The same approximately holds also for edits. Having a large file with a lot of graphics, editing text or moving the cursor at the top of such notebook becomes extremely slow on such weak netbooks. On the contrary, adding code or moving cursor at the end of such file is quick enough not to be noticed.

I have been following the evolution of Mathematica "speed" since v5 and I have to say that there was huge drop of performance when Wolfram switched the backend language to java and ever since the performance of the kernel or the Frontend has been getting worse (the fact substantially masked by the CPU speed increases during the "frequency wars"; now this Moore's law is over...). It also seems that all the incredible performance gains (with JIT technology and loop/execution tracing) in other interpreted languages never really reached Mathematica. Maybe Wolfram should dedicate one major version bump only to address these performance issues otherwise (this great) language may put itself into oblivion.

Nevertheless, the behavior described above is quite odd, i.e. it seems edits at the top are $\mathcal{O}($file size$)$ while at the bottom they are more like $\mathcal{O}(1)$.

Are there any preferences/options that can be tweaked in order to reduce the load Frontend uses for rendering?

share|improve this question
Not sure since I don't notice it on Mac, but here are two ideas: try disabling dynamic updating under the Evaluation menu. Does it make a difference when you shrink the size of the notebook window? (probably not, but who knows)... Also, if you have large cells with lots of formatting or inline cells, maybe try breaking them up into smaller cells/cell groups. – Jens Jul 18 '13 at 17:06
This seems to be a related problem. – Darko Veberic Jul 20 '13 at 15:29
@DarkoVeberic "This" above appears to be a dead link. – Peeter Joot Feb 9 '14 at 6:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.