Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

whos() considerably slow #14173

Closed
hyiltiz opened this issue Nov 28, 2015 · 9 comments
Closed

whos() considerably slow #14173

hyiltiz opened this issue Nov 28, 2015 · 9 comments

Comments

@hyiltiz
Copy link

hyiltiz commented Nov 28, 2015

julia> @time whos()
Base 24573 KB Module : Base
Core 3043 KB Module : Core
Main 808579 KB Module : Main
ans 0 bytes Void : nothing
x 781250 KB 10000x10000 Array{Float64,2} : [0.2345839889343943…
α̂₂ 8 bytes Int64 : 2
203.371041 seconds (1.58 G allocations: 34.022 GB, 4.22% gc time)

@andreasnoack
Copy link
Member

That is really bad. The problem is mainly this line which prints the object. Unfortunately, it prints all the values of the array, which takes quite long time because your array is large. It shouldn't print all the values, but instead do something like we are doing when printing an array in the REPL, but our array printing code is really convoluted, so I'm not sure there is an easy fix.

Hopefully #14052 will be a long term fix for easier array printing, but I'm not sure it is worth the trouble to print the objects in whos. It is mainly their size and type that are interesting.

@Keno
Copy link
Member

Keno commented Nov 28, 2015

Wouldn't replacing that line with showcompact be sufficient?

@hyiltiz
Copy link
Author

hyiltiz commented Nov 28, 2015

I am fairly new to Julia, and am really fascinated by it. All I did was x = rand(1000,1000) and a call to whos(). But I really do not expect to wait about a minute to find out about my workspace. I am not sure what needs to be done, but definitely not trying to print implicitly or explicitly the variables in the workspace.

@andreasnoack
Copy link
Member

Unfortunately, showcompact won't work. It also prints all the values of the array and I think it ends up calling the same method. The more efficient printing in the REPL completely bypasses show and showcompact using writemime and showarray. The reasons for the two different paths for array printing are a bit of a mystery because I don't think it's ever a good idea to fetch all the values of big arrays. For DArray this would probably make the system hang forever.

@hyiltiz
Copy link
Author

hyiltiz commented Nov 29, 2015

@andreasnoack So is that a feature to come in a future release?

@andreasnoack
Copy link
Member

@hyiltiz The fix in #14177 should be possible to backport. The more general refactoring of the printing functions is for future releases.

@hyiltiz
Copy link
Author

hyiltiz commented Nov 29, 2015

I really liked the current behavior (printing head and tail of a big matrix) of the printing function. I hope #14177 does not change that. Instead, whos() only needs to represent properties of the variables in the namespace. So, instead of showing everything, a (maybe hardcoded) head -n 5 could be enough as far as whos() functionality is concerned.

@JeffBezanson
Copy link
Sponsor Member

We should not be trying to show whole values during whos. We should use something like summary.

@andreasnoack
Copy link
Member

@JeffBezanson That is also what I've ended up doing in #14177.

Keno added a commit that referenced this issue Dec 5, 2015
The old threshold causes this test to fail in MEMDEBUG mode
Keno added a commit that referenced this issue Dec 7, 2015
The old threshold causes this test to fail in MEMDEBUG mode
(cherry picked from commit 78bc312)
maleadt added a commit that referenced this issue Aug 17, 2016
The test failed again in MEMDEBUG mode, allocating 19776 bytes (while only 6096 with MEMDEBUG off).
Before #14173, the test allocated 1597240656 bytes, so it is safe to bump this value to 50k.
maleadt added a commit that referenced this issue Aug 18, 2016
Use it to fix the #14173 test in the case of MEMDEBUG.
maleadt added a commit that referenced this issue Aug 18, 2016
Use it to fix the #14173 test in the case of MEMDEBUG.
maleadt added a commit that referenced this issue Aug 20, 2016
Expose MEMDEBUG, and use it to fix the #14173 test
maleadt added a commit that referenced this issue Aug 20, 2016
Expose MEMDEBUG, and use it to fix the #14173 test
maleadt added a commit that referenced this issue Aug 21, 2016
maleadt added a commit that referenced this issue Aug 21, 2016
maleadt added a commit that referenced this issue Aug 21, 2016
One of my ASAN CI builds allocated 21056 bytes on this test, so tweaking the thresholds yet again...
tkelman pushed a commit that referenced this issue Aug 22, 2016
maleadt added a commit that referenced this issue Aug 22, 2016
Increase MEMDEBUG allocation threshold for #14173 test
mfasi pushed a commit to mfasi/julia that referenced this issue Sep 5, 2016
mfasi pushed a commit to mfasi/julia that referenced this issue Sep 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants