# Front end output of my Mathematica is extremely slow

I am using Mathematica 12, take a look at below two runs

I already using Short to shorten output. The first run shows Short is quick. But the second run without ; takes 10 seconds to just output several numbers? Though the timing is weirdly quick.

I also tried command line math, there is no problem with command line mathematica.

What is wrong with my front end? Any workarounds?

update

There are already several comments now, Thank you so much. Let me summarize as below:

compare below three runs

RandomReal[1., 1000000]
RandomReal[1., 1000000] // Short
RandomReal[1., 1000000] // Shallow


There are several weird points:

1. Without ;, only Shallow is fast, the other two are equally extremely slow. With ;, they are all fast. Considering Shallow and Short are quite similar, this is really weird.
2. Define menq[expr_]:=ByteCount[expr]/1024/1024. and apply menq on three expression all gives 7.62958, so output size is not a key factor here.
3. Bob Hanlon reported that macOS does not suffer from this problem. So only windows and linux suffer.
• I cannot reproduce the behavior that you see. Both lines execute and display quickly. I have v12 with macOS 10.15.1 Nov 26 '19 at 2:00
• I get same behavior. But I think it is due to the display part is getting gets counted in the timing. when ";" is missing. Same thing happens like this AbsoluteTiming[Short[RandomReal[1., 100000]]] vs. AbsoluteTiming[Short[RandomReal[1., 100000]];] This could be a bug, since real time shows the same, but it is not actually the same. First case is much slower in real time. V12 on windows 10. Nov 26 '19 at 2:06
• @BobHanlon Thanks for reporting. But I also tested on ubuntu with mathematica 11, same problem. Nov 26 '19 at 2:25
• @Nasser I just found Short doesn't actually shorten results! (RandomReal[1., 1000000] // Short // ByteCount)/1024/1024. shows 7.62MB. But why is that? This is not what I expect from a Short result Nov 26 '19 at 2:41
• @BobHanlon Could you ByteCount in your Mathematica? Nov 26 '19 at 2:43

Short is a formatting wrapper, so that it affects box generation. Basically, I think Short creates the full boxes for the expression, and then it elides various pieces so that the output is shorter. Creating the full boxes is time consuming:

ToBoxes[RandomReal[1, 10^6]]; //AbsoluteTiming


{2.38522, Null}

Creating the Short version of the full boxes should have about the same timing:

ToBoxes[Short @ RandomReal[1, 10^6]]; //AbsoluteTiming


{2.33828, Null}

If the output is not displayed, then the process of creating the full boxes is avoided:

ToBoxes[Short @ RandomReal[1, 10^6];] //AbsoluteTiming


{0.00955, "Null"}

This explains the behavior that you're seeing with regards to timing.

As for the Shallow timing, Shallow does not need to create the full boxes in order to create the Shallow version. Finally, the byte count of all expressions are about the same, because the underlying expressions are basically the same, it is only the boxes generated from the underlying expressions that are different.

• Hi, Carl Woll, Thank you for answering. But why macOS doesn't have such problem? Dec 1 '19 at 1:20
• @matheorem I use macOS and it has the same timing issue for me. Dec 1 '19 at 1:21
• oh, then I do not know why Bob Hanlon has no such issue, maybe a more powerful computer :) Anyway, I still think this is not reasonable, because RandomReal is packed array which is easy to detect, and I think there is nothing worth to make box of. Why direct output of RandomReal[1.,100000] wil be such slow? Dec 1 '19 at 2:23