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

Various Optimizations #359

Merged
merged 6 commits into from Dec 16, 2015

Conversation

Projects
None yet
2 participants
@philippjfr
Copy link
Contributor

philippjfr commented Dec 15, 2015

This is a PR for various optimizations on some of the core components of HoloViews.

@philippjfr philippjfr force-pushed the optimization branch 3 times, most recently from 3f02d8f to fda86cb Dec 15, 2015

if len(labels) == 1:
return list(labels)[0]
if len(self):
return next(itervalues(self.data)).label

This comment has been minimized.

@jlstevens

jlstevens Dec 15, 2015

Contributor

I think you still need to check _auxiliary_component as that marks Annotations where you don't want to propagate the label upwards.

This comment has been minimized.

@philippjfr

philippjfr Dec 15, 2015

Author Contributor

Bottom layer should usually not be an annotation but I can just throw a while loop in there that'll iterate until it finds a non-auxiliar component.

This comment has been minimized.

@jlstevens

jlstevens Dec 15, 2015

Contributor

My understanding is that label should be the empty string if the first value (i.e the one we are inspecting) is an _auxiliary_component. Before we were iterating over the NdMapping elements: when you say the bottom layer shouldn't be an annotation, I believe you are thinking about Overlay elements. In other words, I think we need this check for HoloMaps of annotations.

@philippjfr philippjfr force-pushed the optimization branch from fda86cb to 1c330be Dec 15, 2015

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented Dec 15, 2015

One quick comment: the code looks good but seems to repeat itself (almost exactly, but not quite) between group and label. I would consider a utility or this, either a function with an option to get the group or label, or maybe a class with two classmethods get_group and get_label.

Otherwise it looks good and I am happy to merge.

@philippjfr philippjfr force-pushed the optimization branch from 2f59211 to f2e6931 Dec 16, 2015

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented on 0679b76 Dec 16, 2015

Looks good!

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented on holoviews/core/data.py in 931b06b Dec 16, 2015

I'm not sure how this is being used outside this file but I don't see much use for this from a user perspective. It could be a utility and I am happy for this on the interface classes but not on Columns itself (unless you can convince me that users will want it).

Edit: I somewhat changed my mind in the comment below.

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented on holoviews/core/data.py in 931b06b Dec 16, 2015

Ah. This method already exists on Dimensioned, in which case it is consistent. Looking at Dimensioned.dimension_type, I see that it isn't entirely trivial as it infers the dimension type from dimension_values (if not declared). I don't think users will use this often but I'm no longer going to argue that this should necessarily be a utility.

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented on 931b06b Dec 16, 2015

Looks fine as this makes Columns consistent with Dimensioned. I don't see myself using dimension_type very often though...

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented on holoviews/core/util.py in f2e6931 Dec 16, 2015

Right. This was the main difference between how groups and labels were processed.

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented Dec 16, 2015

Looks good once the tests are passing.

One thing you didn't mention at the start of the PR was how slow the old label/group processing was. I know this will offer some sort of performance improvement but I don't have a feeling for what kind of speed up I can expect and in which situations.

Philipp Rudiger added some commits Dec 16, 2015

@philippjfr

This comment has been minimized.

Copy link
Contributor Author

philippjfr commented Dec 16, 2015

This PR is ready for merge now that the tests are passing.

jlstevens added a commit that referenced this pull request Dec 16, 2015

Merge pull request #359 from ioam/optimization
Various Optimizations

@jlstevens jlstevens merged commit 3084b68 into master Dec 16, 2015

3 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls Coverage increased (+0.02%) to 71.07%
Details
@philippjfr

This comment has been minimized.

Copy link
Contributor Author

philippjfr commented Dec 16, 2015

One thing you didn't mention at the start of the PR was how slow the old label/group processing was. I know this will offer some sort of performance improvement but I don't have a feeling for what kind of speed up I can expect and in which situations.

For very nested datastructures it saves a lot of time. I tested it on plotting a HoloMap of 1000 Overlays each containing 100 Curves, in that example it saved 120/130 seconds.

@jlstevens

This comment has been minimized.

Copy link
Contributor

jlstevens commented Dec 16, 2015

Thanks. That is a plausible holomap and 120 seconds is a significant saving - although you didn't say how long it took in total. :-)

Edit: Philipp tells me it saved 120 seconds from 130 seconds. A huge improvement indeed!

@philippjfr philippjfr deleted the optimization branch Dec 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.