Skip to content

Conversation

@dodamih
Copy link

@dodamih dodamih commented Jan 1, 2026

No description provided.

Copy link
Contributor

@william-silversmith william-silversmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great start! I think it's pretty close. Can you add a test or two that uses this flag?

@dodamih
Copy link
Author

dodamih commented Jan 2, 2026

Fixed the things you mentioned.

return cseg.compress(subvol, block_size=block_size, order=order)

def encode_raw(subvol):
if not subvol.flags['F_CONTIGUOUS']:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this optimization. It's true that tobytes will run very fast, but that's because the expensive part is getting done in asfortranarray. Secondly, asfortranarray doesn't do anything when it's already in fortran order so the if statement isn't necessary.

Copy link
Author

@dodamih dodamih Jan 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested this and asfortranarray + tobytes is much faster than tobytes for C order arrays above a certain size (70% speedup for 64MB), and 50% speedup for non-contiguous slices. I forget if C order arrays can even make it this far without conversion, but non-contiguous slices definitely can. I will remove the if statement, but the performance benefit is there if you can accept the small memory cost of making a copy of the chunk - guessing that tobytes doesn't bother making a contiguous copy.

As a side note, what I really need is an option to skip the encoding and just keep the volume in memory because I'm spending nontrivial amount of time (20% of the entire task time) serialising / deserialising temporary volumes being written to mem://, but I'm not sure how you feel about extending to just keeping raw arrays in memory. The nontrivial time being spent on encoding was why I was looking into the optimisation.

@william-silversmith william-silversmith added the feature A new capability is born. label Jan 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature A new capability is born.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants