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

NMatrix getter and setter way slower than Matrix #541

Closed
lokeshh opened this issue Sep 4, 2016 · 4 comments · Fixed by #542
Closed

NMatrix getter and setter way slower than Matrix #541

lokeshh opened this issue Sep 4, 2016 · 4 comments · Fixed by #542

Comments

@lokeshh
Copy link
Member

lokeshh commented Sep 4, 2016

I'm using NMatrix for competitive programming for a while now and I have found NMatrix to be slower than Matrix for most of my programs. For example methods such as [], []= which are frequently used in my programs are slower in NMatrix.

Here's a benchmark I ran and following are the results:

       user     system      total        real
Matrix getter  3.700000   0.020000   3.720000 (  3.744560)
NMatrix getter 12.930000   0.060000  12.990000 ( 13.065677)
Matrix setter  2.920000   0.020000   2.940000 (  2.965361)
NMatrix setter 16.600000   0.060000  16.660000 ( 16.889194)
@v0dro
Copy link
Member

v0dro commented Sep 4, 2016

Damn that sucks. Need some urgent performance fixes for nmatrix.

@wlevine
Copy link

wlevine commented Sep 4, 2016

@lokeshh Good catch! I think this is due to a lot of heap allocation of SLICE objects, which can be avoided. I will try to have a patch soon.

@wlevine
Copy link

wlevine commented Sep 4, 2016

For #[]=, I notice that we're spending a lot of time in nm::dense_storage::set(), allocating and freeing stuff. I'm not going to look into this any more at the moment, just noting this for future reference.

@translunar
Copy link
Member

Thanks for looking into this, @wlevine. I concur with your explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants