WIP, RFC: Optimize setitem with chunk equal to fill_value by jakirkham · Pull Request #367 · zarr-developers/zarr-python

jakirkham · 2018-12-16T06:54:45Z

If a chunk only contains the fill_value, delete the key-value pair for that chunk instead of storing the array. Should cutdown on storage space require for the Array. Also should improve the performance of copying one Array to another.

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/tutorial.rst
Changes documented in docs/release.rst
Docs build locally (e.g., run tox -e docs)
AppVeyor and Travis CI passes
Test coverage is 100% (Coveralls passes)

Matches how these lines are written in `_set_basic_selection_zd`.

Add a simple check to see if the key-value pair is just being set with a chunk equal to the fill value. If so, simply delete the key-value pair instead of storing a chunk that only contains the fill value. The Array will behave the same externally. However this will cutdown on the space require to store the Array. Also will make sure that copying one Array to another Array won't dramatically effect the storage size.

rabernat · 2019-09-17T14:14:48Z

I have a very large, relatively sparse (lots of empty chunks) array. I would really like to avoid writing all those empty chunks to disk.

So 👍 to this!

rabernat · 2019-09-17T14:15:25Z

 chunk[selection] = value

+ # clear chunk if it only contains the fill value
+ if np.all(np.equal(chunk, self._fill_value)):


This seems like it could sometimes be an expensive operation. So it should be optional.

How large are typical chunk sizes for you?

regardless of chunk size, in many cases the user knows in advance whether this check will ever be useful. For dense imaging data, this conditional will almost never evaluate to true; for sparse data, this conditional will often evaluate to true. So the user should have some discretion over whether this check occurs.

jakirkham · 2019-09-17T21:28:16Z

Thanks! Yeah that was the idea behind it.

There was funkiness with ZipStore as deletion is not supported there.

Can give this another look 🙂

joshmoore · 2021-02-18T17:18:29Z

I actually assumed recently that this was the default.

jakirkham · 2021-02-19T00:41:40Z

Nope, but I think we discussed recently how we might get this to work for ZipStore and other non-deletable stores by just making the value b''. So I think we may be able to generalize this a bit

d-v-b · 2021-04-25T17:27:35Z

I was also bitten by thinking that was the default! Would love to see this merged.

d-v-b · 2021-05-10T23:00:56Z

@jakirkham I would be happy to move this PR forward, but I don't think I have push access to your fork. I made some changes (added a kwarg to the Array constructor, and added tests) here: https://github.com/d-v-b/zarr-python/tree/opt_setitem_fill_value

jakirkham · 2021-05-11T02:07:08Z

Sounds good. In that case feel free to send a PR to zarr-developers. Am going to close this out.

jakirkham · 2018-12-16T06:54:45Z

Fixes#366

If a chunk only contains the fill_value, delete the key-value pair for that chunk instead of storing the array. Should cutdown on storage space require for the Array. Also should improve the performance of copying one Array to another.

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/tutorial.rst
Changes documented in docs/release.rst
Docs build locally (e.g., run tox -e docs)
AppVeyor and Travis CI passes
Test coverage is 100% (Coveralls passes)

Matches how these lines are written in `_set_basic_selection_zd`.

Add a simple check to see if the key-value pair is just being set with a chunk equal to the fill value. If so, simply delete the key-value pair instead of storing a chunk that only contains the fill value. The Array will behave the same externally. However this will cutdown on the space require to store the Array. Also will make sure that copying one Array to another Array won't dramatically effect the storage size.

rabernat · 2019-09-17T14:14:48Z

I have a very large, relatively sparse (lots of empty chunks) array. I would really like to avoid writing all those empty chunks to disk.

So 👍 to this!

rabernat · 2019-09-17T14:15:25Z

 chunk[selection] = value

+ # clear chunk if it only contains the fill value
+ if np.all(np.equal(chunk, self._fill_value)):


This seems like it could sometimes be an expensive operation. So it should be optional.

How large are typical chunk sizes for you?

regardless of chunk size, in many cases the user knows in advance whether this check will ever be useful. For dense imaging data, this conditional will almost never evaluate to true; for sparse data, this conditional will often evaluate to true. So the user should have some discretion over whether this check occurs.

jakirkham · 2019-09-17T21:28:16Z

Thanks! Yeah that was the idea behind it.

There was funkiness with ZipStore as deletion is not supported there.

Can give this another look 🙂

joshmoore · 2021-02-18T17:18:29Z

I actually assumed recently that this was the default.

jakirkham · 2021-02-19T00:41:40Z

Nope, but I think we discussed recently how we might get this to work for ZipStore and other non-deletable stores by just making the value b''. So I think we may be able to generalize this a bit

d-v-b · 2021-04-25T17:27:35Z

I was also bitten by thinking that was the default! Would love to see this merged.

d-v-b · 2021-05-10T23:00:56Z

@jakirkham I would be happy to move this PR forward, but I don't think I have push access to your fork. I made some changes (added a kwarg to the Array constructor, and added tests) here: https://github.com/d-v-b/zarr-python/tree/opt_setitem_fill_value

jakirkham · 2021-05-11T02:07:08Z

Sounds good. In that case feel free to send a PR to zarr-developers. Am going to close this out.

jakirkham · 2018-12-16T06:54:45Z

Fixes#366

If a chunk only contains the fill_value, delete the key-value pair for that chunk instead of storing the array. Should cutdown on storage space require for the Array. Also should improve the performance of copying one Array to another.

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/tutorial.rst
Changes documented in docs/release.rst
Docs build locally (e.g., run tox -e docs)
AppVeyor and Travis CI passes
Test coverage is 100% (Coveralls passes)

Matches how these lines are written in `_set_basic_selection_zd`.

Add a simple check to see if the key-value pair is just being set with a chunk equal to the fill value. If so, simply delete the key-value pair instead of storing a chunk that only contains the fill value. The Array will behave the same externally. However this will cutdown on the space require to store the Array. Also will make sure that copying one Array to another Array won't dramatically effect the storage size.

rabernat · 2019-09-17T14:14:48Z

I have a very large, relatively sparse (lots of empty chunks) array. I would really like to avoid writing all those empty chunks to disk.

So 👍 to this!

rabernat · 2019-09-17T14:15:25Z

 chunk[selection] = value

+ # clear chunk if it only contains the fill value
+ if np.all(np.equal(chunk, self._fill_value)):


This seems like it could sometimes be an expensive operation. So it should be optional.

How large are typical chunk sizes for you?

regardless of chunk size, in many cases the user knows in advance whether this check will ever be useful. For dense imaging data, this conditional will almost never evaluate to true; for sparse data, this conditional will often evaluate to true. So the user should have some discretion over whether this check occurs.

jakirkham · 2019-09-17T21:28:16Z

Thanks! Yeah that was the idea behind it.

There was funkiness with ZipStore as deletion is not supported there.

Can give this another look 🙂

joshmoore · 2021-02-18T17:18:29Z

I actually assumed recently that this was the default.

jakirkham · 2021-02-19T00:41:40Z

Nope, but I think we discussed recently how we might get this to work for ZipStore and other non-deletable stores by just making the value b''. So I think we may be able to generalize this a bit

d-v-b · 2021-04-25T17:27:35Z

I was also bitten by thinking that was the default! Would love to see this merged.

d-v-b · 2021-05-10T23:00:56Z

@jakirkham I would be happy to move this PR forward, but I don't think I have push access to your fork. I made some changes (added a kwarg to the Array constructor, and added tests) here: https://github.com/d-v-b/zarr-python/tree/opt_setitem_fill_value

jakirkham · 2021-05-11T02:07:08Z

Sounds good. In that case feel free to send a PR to zarr-developers. Am going to close this out.

jakirkham · 2018-12-16T06:54:45Z

Fixes#366

If a chunk only contains the fill_value, delete the key-value pair for that chunk instead of storing the array. Should cutdown on storage space require for the Array. Also should improve the performance of copying one Array to another.

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/tutorial.rst
Changes documented in docs/release.rst
Docs build locally (e.g., run tox -e docs)
AppVeyor and Travis CI passes
Test coverage is 100% (Coveralls passes)

Matches how these lines are written in `_set_basic_selection_zd`.

Add a simple check to see if the key-value pair is just being set with a chunk equal to the fill value. If so, simply delete the key-value pair instead of storing a chunk that only contains the fill value. The Array will behave the same externally. However this will cutdown on the space require to store the Array. Also will make sure that copying one Array to another Array won't dramatically effect the storage size.

rabernat · 2019-09-17T14:14:48Z

I have a very large, relatively sparse (lots of empty chunks) array. I would really like to avoid writing all those empty chunks to disk.

So 👍 to this!

rabernat · 2019-09-17T14:15:25Z

 chunk[selection] = value

+ # clear chunk if it only contains the fill value
+ if np.all(np.equal(chunk, self._fill_value)):


This seems like it could sometimes be an expensive operation. So it should be optional.

How large are typical chunk sizes for you?

regardless of chunk size, in many cases the user knows in advance whether this check will ever be useful. For dense imaging data, this conditional will almost never evaluate to true; for sparse data, this conditional will often evaluate to true. So the user should have some discretion over whether this check occurs.

jakirkham · 2019-09-17T21:28:16Z

Thanks! Yeah that was the idea behind it.

There was funkiness with ZipStore as deletion is not supported there.

Can give this another look 🙂

joshmoore · 2021-02-18T17:18:29Z

I actually assumed recently that this was the default.

jakirkham · 2021-02-19T00:41:40Z

Nope, but I think we discussed recently how we might get this to work for ZipStore and other non-deletable stores by just making the value b''. So I think we may be able to generalize this a bit

d-v-b · 2021-04-25T17:27:35Z

I was also bitten by thinking that was the default! Would love to see this merged.

d-v-b · 2021-05-10T23:00:56Z

@jakirkham I would be happy to move this PR forward, but I don't think I have push access to your fork. I made some changes (added a kwarg to the Array constructor, and added tests) here: https://github.com/d-v-b/zarr-python/tree/opt_setitem_fill_value

jakirkham · 2021-05-11T02:07:08Z

Sounds good. In that case feel free to send a PR to zarr-developers. Am going to close this out.

jakirkham · 2018-12-16T06:54:45Z

Fixes#366

If a chunk only contains the fill_value, delete the key-value pair for that chunk instead of storing the array. Should cutdown on storage space require for the Array. Also should improve the performance of copying one Array to another.

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/tutorial.rst
Changes documented in docs/release.rst
Docs build locally (e.g., run tox -e docs)
AppVeyor and Travis CI passes
Test coverage is 100% (Coveralls passes)

Matches how these lines are written in `_set_basic_selection_zd`.

Add a simple check to see if the key-value pair is just being set with a chunk equal to the fill value. If so, simply delete the key-value pair instead of storing a chunk that only contains the fill value. The Array will behave the same externally. However this will cutdown on the space require to store the Array. Also will make sure that copying one Array to another Array won't dramatically effect the storage size.

rabernat · 2019-09-17T14:14:48Z

I have a very large, relatively sparse (lots of empty chunks) array. I would really like to avoid writing all those empty chunks to disk.

So 👍 to this!

rabernat · 2019-09-17T14:15:25Z

 chunk[selection] = value

+ # clear chunk if it only contains the fill value
+ if np.all(np.equal(chunk, self._fill_value)):


This seems like it could sometimes be an expensive operation. So it should be optional.

How large are typical chunk sizes for you?

regardless of chunk size, in many cases the user knows in advance whether this check will ever be useful. For dense imaging data, this conditional will almost never evaluate to true; for sparse data, this conditional will often evaluate to true. So the user should have some discretion over whether this check occurs.

jakirkham · 2019-09-17T21:28:16Z

Thanks! Yeah that was the idea behind it.

There was funkiness with ZipStore as deletion is not supported there.

Can give this another look 🙂

joshmoore · 2021-02-18T17:18:29Z

I actually assumed recently that this was the default.

jakirkham · 2021-02-19T00:41:40Z

Nope, but I think we discussed recently how we might get this to work for ZipStore and other non-deletable stores by just making the value b''. So I think we may be able to generalize this a bit

d-v-b · 2021-04-25T17:27:35Z

I was also bitten by thinking that was the default! Would love to see this merged.

d-v-b · 2021-05-10T23:00:56Z

@jakirkham I would be happy to move this PR forward, but I don't think I have push access to your fork. I made some changes (added a kwarg to the Array constructor, and added tests) here: https://github.com/d-v-b/zarr-python/tree/opt_setitem_fill_value

jakirkham · 2021-05-11T02:07:08Z

Sounds good. In that case feel free to send a PR to zarr-developers. Am going to close this out.

jakirkham · 2018-12-16T06:54:45Z

Fixes#366

If a chunk only contains the fill_value, delete the key-value pair for that chunk instead of storing the array. Should cutdown on storage space require for the Array. Also should improve the performance of copying one Array to another.

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/tutorial.rst
Changes documented in docs/release.rst
Docs build locally (e.g., run tox -e docs)
AppVeyor and Travis CI passes
Test coverage is 100% (Coveralls passes)

Matches how these lines are written in `_set_basic_selection_zd`.

Add a simple check to see if the key-value pair is just being set with a chunk equal to the fill value. If so, simply delete the key-value pair instead of storing a chunk that only contains the fill value. The Array will behave the same externally. However this will cutdown on the space require to store the Array. Also will make sure that copying one Array to another Array won't dramatically effect the storage size.

rabernat · 2019-09-17T14:14:48Z

I have a very large, relatively sparse (lots of empty chunks) array. I would really like to avoid writing all those empty chunks to disk.

So 👍 to this!

rabernat · 2019-09-17T14:15:25Z

 chunk[selection] = value

+ # clear chunk if it only contains the fill value
+ if np.all(np.equal(chunk, self._fill_value)):


This seems like it could sometimes be an expensive operation. So it should be optional.

How large are typical chunk sizes for you?

regardless of chunk size, in many cases the user knows in advance whether this check will ever be useful. For dense imaging data, this conditional will almost never evaluate to true; for sparse data, this conditional will often evaluate to true. So the user should have some discretion over whether this check occurs.

jakirkham · 2019-09-17T21:28:16Z

Thanks! Yeah that was the idea behind it.

There was funkiness with ZipStore as deletion is not supported there.

Can give this another look 🙂

joshmoore · 2021-02-18T17:18:29Z

I actually assumed recently that this was the default.

jakirkham · 2021-02-19T00:41:40Z

Nope, but I think we discussed recently how we might get this to work for ZipStore and other non-deletable stores by just making the value b''. So I think we may be able to generalize this a bit

d-v-b · 2021-04-25T17:27:35Z

I was also bitten by thinking that was the default! Would love to see this merged.

d-v-b · 2021-05-10T23:00:56Z

@jakirkham I would be happy to move this PR forward, but I don't think I have push access to your fork. I made some changes (added a kwarg to the Array constructor, and added tests) here: https://github.com/d-v-b/zarr-python/tree/opt_setitem_fill_value

jakirkham · 2021-05-11T02:07:08Z

Sounds good. In that case feel free to send a PR to zarr-developers. Am going to close this out.

jakirkham · 2018-12-16T06:54:45Z

Fixes#366

If a chunk only contains the fill_value, delete the key-value pair for that chunk instead of storing the array. Should cutdown on storage space require for the Array. Also should improve the performance of copying one Array to another.

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/tutorial.rst
Changes documented in docs/release.rst
Docs build locally (e.g., run tox -e docs)
AppVeyor and Travis CI passes
Test coverage is 100% (Coveralls passes)

Matches how these lines are written in `_set_basic_selection_zd`.

Add a simple check to see if the key-value pair is just being set with a chunk equal to the fill value. If so, simply delete the key-value pair instead of storing a chunk that only contains the fill value. The Array will behave the same externally. However this will cutdown on the space require to store the Array. Also will make sure that copying one Array to another Array won't dramatically effect the storage size.

rabernat · 2019-09-17T14:14:48Z

I have a very large, relatively sparse (lots of empty chunks) array. I would really like to avoid writing all those empty chunks to disk.

So 👍 to this!

rabernat · 2019-09-17T14:15:25Z

 chunk[selection] = value

+ # clear chunk if it only contains the fill value
+ if np.all(np.equal(chunk, self._fill_value)):


This seems like it could sometimes be an expensive operation. So it should be optional.

How large are typical chunk sizes for you?

regardless of chunk size, in many cases the user knows in advance whether this check will ever be useful. For dense imaging data, this conditional will almost never evaluate to true; for sparse data, this conditional will often evaluate to true. So the user should have some discretion over whether this check occurs.

jakirkham · 2019-09-17T21:28:16Z

Thanks! Yeah that was the idea behind it.

There was funkiness with ZipStore as deletion is not supported there.

Can give this another look 🙂

joshmoore · 2021-02-18T17:18:29Z

I actually assumed recently that this was the default.

jakirkham · 2021-02-19T00:41:40Z

Nope, but I think we discussed recently how we might get this to work for ZipStore and other non-deletable stores by just making the value b''. So I think we may be able to generalize this a bit

d-v-b · 2021-04-25T17:27:35Z

I was also bitten by thinking that was the default! Would love to see this merged.

d-v-b · 2021-05-10T23:00:56Z

@jakirkham I would be happy to move this PR forward, but I don't think I have push access to your fork. I made some changes (added a kwarg to the Array constructor, and added tests) here: https://github.com/d-v-b/zarr-python/tree/opt_setitem_fill_value

jakirkham · 2021-05-11T02:07:08Z

Sounds good. In that case feel free to send a PR to zarr-developers. Am going to close this out.

jakirkham · 2018-12-16T06:54:45Z

Fixes#366

If a chunk only contains the fill_value, delete the key-value pair for that chunk instead of storing the array. Should cutdown on storage space require for the Array. Also should improve the performance of copying one Array to another.

TODO:

Add unit tests and/or doctests in docstrings
Add docstrings and API docs for any new/modified user-facing classes and functions
New/modified features documented in docs/tutorial.rst
Changes documented in docs/release.rst
Docs build locally (e.g., run tox -e docs)
AppVeyor and Travis CI passes
Test coverage is 100% (Coveralls passes)

Matches how these lines are written in `_set_basic_selection_zd`.

Add a simple check to see if the key-value pair is just being set with a chunk equal to the fill value. If so, simply delete the key-value pair instead of storing a chunk that only contains the fill value. The Array will behave the same externally. However this will cutdown on the space require to store the Array. Also will make sure that copying one Array to another Array won't dramatically effect the storage size.

rabernat · 2019-09-17T14:14:48Z

I have a very large, relatively sparse (lots of empty chunks) array. I would really like to avoid writing all those empty chunks to disk.

So 👍 to this!

rabernat · 2019-09-17T14:15:25Z

 chunk[selection] = value

+ # clear chunk if it only contains the fill value
+ if np.all(np.equal(chunk, self._fill_value)):


This seems like it could sometimes be an expensive operation. So it should be optional.

How large are typical chunk sizes for you?

regardless of chunk size, in many cases the user knows in advance whether this check will ever be useful. For dense imaging data, this conditional will almost never evaluate to true; for sparse data, this conditional will often evaluate to true. So the user should have some discretion over whether this check occurs.

jakirkham · 2019-09-17T21:28:16Z

Thanks! Yeah that was the idea behind it.

There was funkiness with ZipStore as deletion is not supported there.

Can give this another look 🙂

joshmoore · 2021-02-18T17:18:29Z

I actually assumed recently that this was the default.

jakirkham · 2021-02-19T00:41:40Z

Nope, but I think we discussed recently how we might get this to work for ZipStore and other non-deletable stores by just making the value b''. So I think we may be able to generalize this a bit

d-v-b · 2021-04-25T17:27:35Z

I was also bitten by thinking that was the default! Would love to see this merged.

d-v-b · 2021-05-10T23:00:56Z

@jakirkham I would be happy to move this PR forward, but I don't think I have push access to your fork. I made some changes (added a kwarg to the Array constructor, and added tests) here: https://github.com/d-v-b/zarr-python/tree/opt_setitem_fill_value

jakirkham · 2021-05-11T02:07:08Z

Sounds good. In that case feel free to send a PR to zarr-developers. Am going to close this out.

Consolidate encode/store in _chunk_setitem_nosync
8153810
Matches how these lines are written in `_set_basic_selection_zd`.

jakirkham mentioned this pull request Dec 16, 2018
Optimize storing fill_value to Array #366
Closed

rabernat reviewed Sep 17, 2019
View reviewed changes

jakirkham closed this May 11, 2021

jakirkham deleted the opt_setitem_fill_value branch May 11, 2021 02:07

d-v-b mentioned this pull request May 11, 2021
Optimize setitem with chunk equal to fill_value, round 2 #738
Merged
6 tasks

Consolidate encode/store in _chunk_setitem_nosync
8153810
Matches how these lines are written in `_set_basic_selection_zd`.

jakirkham mentioned this pull request Dec 16, 2018
Optimize storing fill_value to Array #366
Closed

rabernat reviewed Sep 17, 2019
View reviewed changes

jakirkham closed this May 11, 2021

jakirkham deleted the opt_setitem_fill_value branch May 11, 2021 02:07

d-v-b mentioned this pull request May 11, 2021
Optimize setitem with chunk equal to fill_value, round 2 #738
Merged
6 tasks

Consolidate encode/store in _chunk_setitem_nosync
8153810
Matches how these lines are written in `_set_basic_selection_zd`.

jakirkham mentioned this pull request Dec 16, 2018
Optimize storing fill_value to Array #366
Closed

rabernat reviewed Sep 17, 2019
View reviewed changes

jakirkham closed this May 11, 2021

jakirkham deleted the opt_setitem_fill_value branch May 11, 2021 02:07

d-v-b mentioned this pull request May 11, 2021
Optimize setitem with chunk equal to fill_value, round 2 #738
Merged
6 tasks

Consolidate encode/store in _chunk_setitem_nosync
8153810
Matches how these lines are written in `_set_basic_selection_zd`.

jakirkham mentioned this pull request Dec 16, 2018
Optimize storing fill_value to Array #366
Closed

rabernat reviewed Sep 17, 2019
View reviewed changes

jakirkham closed this May 11, 2021

jakirkham deleted the opt_setitem_fill_value branch May 11, 2021 02:07

d-v-b mentioned this pull request May 11, 2021
Optimize setitem with chunk equal to fill_value, round 2 #738
Merged
6 tasks

Consolidate encode/store in _chunk_setitem_nosync
8153810
Matches how these lines are written in `_set_basic_selection_zd`.

jakirkham mentioned this pull request Dec 16, 2018
Optimize storing fill_value to Array #366
Closed

rabernat reviewed Sep 17, 2019
View reviewed changes

jakirkham closed this May 11, 2021

jakirkham deleted the opt_setitem_fill_value branch May 11, 2021 02:07

d-v-b mentioned this pull request May 11, 2021
Optimize setitem with chunk equal to fill_value, round 2 #738
Merged
6 tasks

Consolidate encode/store in _chunk_setitem_nosync
8153810
Matches how these lines are written in `_set_basic_selection_zd`.

jakirkham mentioned this pull request Dec 16, 2018
Optimize storing fill_value to Array #366
Closed

rabernat reviewed Sep 17, 2019
View reviewed changes

jakirkham closed this May 11, 2021

jakirkham deleted the opt_setitem_fill_value branch May 11, 2021 02:07

d-v-b mentioned this pull request May 11, 2021
Optimize setitem with chunk equal to fill_value, round 2 #738
Merged
6 tasks

Consolidate encode/store in _chunk_setitem_nosync
8153810
Matches how these lines are written in `_set_basic_selection_zd`.

jakirkham mentioned this pull request Dec 16, 2018
Optimize storing fill_value to Array #366
Closed

rabernat reviewed Sep 17, 2019
View reviewed changes

jakirkham closed this May 11, 2021

jakirkham deleted the opt_setitem_fill_value branch May 11, 2021 02:07

d-v-b mentioned this pull request May 11, 2021
Optimize setitem with chunk equal to fill_value, round 2 #738
Merged
6 tasks

Consolidate encode/store in _chunk_setitem_nosync
8153810
Matches how these lines are written in `_set_basic_selection_zd`.

jakirkham mentioned this pull request Dec 16, 2018
Optimize storing fill_value to Array #366
Closed

rabernat reviewed Sep 17, 2019
View reviewed changes

jakirkham closed this May 11, 2021

jakirkham deleted the opt_setitem_fill_value branch May 11, 2021 02:07

d-v-b mentioned this pull request May 11, 2021
Optimize setitem with chunk equal to fill_value, round 2 #738
Merged
6 tasks

Uh oh!

Uh oh!

Conversation

jakirkham commented Dec 16, 2018

Uh oh!

rabernat commented Sep 17, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d-v-bApr 27, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakirkham commented Sep 17, 2019

Uh oh!

joshmoore commented Feb 18, 2021

Uh oh!

jakirkham commented Feb 19, 2021

Uh oh!

d-v-b commented Apr 25, 2021

Uh oh!

d-v-b commented May 10, 2021

Uh oh!

jakirkham commented May 11, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

jakirkham commented Dec 16, 2018

Uh oh!

rabernat commented Sep 17, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d-v-bApr 27, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakirkham commented Sep 17, 2019

Uh oh!

joshmoore commented Feb 18, 2021

Uh oh!

jakirkham commented Feb 19, 2021

Uh oh!

d-v-b commented Apr 25, 2021

Uh oh!

d-v-b commented May 10, 2021

Uh oh!

jakirkham commented May 11, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

jakirkham commented Dec 16, 2018

Uh oh!

rabernat commented Sep 17, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

d-v-bApr 27, 2021•
edited
Loading

d-v-bApr 27, 2021•
edited
Loading

d-v-bApr 27, 2021•
edited
Loading

d-v-bApr 27, 2021•
edited
Loading