Title: Poor performance when creating large numbers of quantities · Issue #260 · python-quantities/python-quantities · GitHub
Open Graph Title: Poor performance when creating large numbers of quantities · Issue #260 · python-quantities/python-quantities
X Title: Poor performance when creating large numbers of quantities · Issue #260 · python-quantities/python-quantities
Description: I would like to report a use case where we find specific design choices in quantities become a major computational bottleneck. Essentially creating a quantity costs a substantial computational overhead and in situation where large number...
Open Graph Description: I would like to report a use case where we find specific design choices in quantities become a major computational bottleneck. Essentially creating a quantity costs a substantial computational over...
X Description: I would like to report a use case where we find specific design choices in quantities become a major computational bottleneck. Essentially creating a quantity costs a substantial computational over...
Opengraph URL: https://github.com/python-quantities/python-quantities/issues/260
X: @github
Domain: github.com
{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Poor performance when creating large numbers of quantities","articleBody":"I would like to report a use case where we find specific design choices in quantities become a major computational bottleneck.\n\nEssentially creating a quantity costs a substantial computational overhead and in situation where large numbers have to be created\nor manipulated this can become the dominant computational cost of the operations. In our specific situation, we are recording hundreds of thousands of neurons which have sparse firing rates and storing them in the Neo SpikeTrainLists which in turn represent each spike train as quantity. In such situation this overhead becomes a dominant factor when for example loading such SpikeTrainLists from pickled storage. \n\nMy preliminary profiling indicates that ultimately the overhead comes down to the function _quantity.validate_dimensionality_ which\ncalls _isinstance_. Apparently _isinstance_ is notoriously expensive internal Python operation. There also seems to be unnecessary doubling of the _isinstance_ call in _quantity.validate_unit_quantity_ when called from _quantity.validate_dimensionality_. \n\nI believe that avoiding the latter unnecessary double call to _isinstance_ would already substantially improve the performance, but the \nultimate solution would need reevaluation if call to these heavy internal Python operations is unavoidable during the creation of \nevery single quantity. Perhaps a solution that would allow for creation of large number of Quantities together that make these \ncalls only once for all of them would be a solution that the upstream packages could use to optimize such specific use cases.","author":{"url":"https://github.com/antolikjan","@type":"Person","name":"antolikjan"},"datePublished":"2025-07-04T15:06:05.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/260/python-quantities/issues/260"}
| route-pattern | /_view_fragments/issues/show/:user_id/:repository/:id/issue_layout(.:format) |
| route-controller | voltron_issues_fragments |
| route-action | issue_layout |
| fetch-nonce | v2:2dbd5eb3-eecc-dee5-bd7a-0915dd13c351 |
| current-catalog-service-hash | 81bb79d38c15960b92d99bca9288a9108c7a47b18f2423d0f6438c5b7bcd2114 |
| request-id | E6CE:9124A:275FF66:33607A2:696B5E65 |
| html-safe-nonce | dbdaab71dc79b3befe9af5e5c4fbf9477a8be50006955b7265acff854ae17f0c |
| visitor-payload | eyJyZWZlcnJlciI6IiIsInJlcXVlc3RfaWQiOiJFNkNFOjkxMjRBOjI3NUZGNjY6MzM2MDdBMjo2OTZCNUU2NSIsInZpc2l0b3JfaWQiOiIyODA5MjQ0NjkwMjQ4NTg4OTAxIiwicmVnaW9uX2VkZ2UiOiJpYWQiLCJyZWdpb25fcmVuZGVyIjoiaWFkIn0= |
| visitor-hmac | 045777e92c1f2ed4720044edd5071e06c7e1c03369ea4751d28d159411abb3d6 |
| hovercard-subject-tag | issue:3203063113 |
| github-keyboard-shortcuts | repository,issues,copilot |
| google-site-verification | Apib7-x98H0j5cPqHWwSMm6dNU4GmODRoqxLiDzdx9I |
| octolytics-url | https://collector.github.com/github/collect |
| analytics-location | / |
| fb:app_id | 1401488693436528 |
| apple-itunes-app | app-id=1477376905, app-argument=https://github.com/_view_fragments/issues/show/python-quantities/python-quantities/260/issue_layout |
| twitter:image | https://opengraph.githubassets.com/47a97c4e4f801e05b3242454b432fdf35424527b4f3429227d0fc9c8f6b05416/python-quantities/python-quantities/issues/260 |
| twitter:card | summary_large_image |
| og:image | https://opengraph.githubassets.com/47a97c4e4f801e05b3242454b432fdf35424527b4f3429227d0fc9c8f6b05416/python-quantities/python-quantities/issues/260 |
| og:image:alt | I would like to report a use case where we find specific design choices in quantities become a major computational bottleneck. Essentially creating a quantity costs a substantial computational over... |
| og:image:width | 1200 |
| og:image:height | 600 |
| og:site_name | GitHub |
| og:type | object |
| og:author:username | antolikjan |
| hostname | github.com |
| expected-hostname | github.com |
| None | 5f99f7c1d70f01da5b93e5ca90303359738944d8ab470e396496262c66e60b8d |
| turbo-cache-control | no-preview |
| go-import | github.com/python-quantities/python-quantities git https://github.com/python-quantities/python-quantities.git |
| octolytics-dimension-user_id | 222003 |
| octolytics-dimension-user_login | python-quantities |
| octolytics-dimension-repository_id | 560911 |
| octolytics-dimension-repository_nwo | python-quantities/python-quantities |
| octolytics-dimension-repository_public | true |
| octolytics-dimension-repository_is_fork | false |
| octolytics-dimension-repository_network_root_id | 560911 |
| octolytics-dimension-repository_network_root_nwo | python-quantities/python-quantities |
| turbo-body-classes | logged-out env-production page-responsive |
| disable-turbo | false |
| browser-stats-url | https://api.github.com/_private/browser/stats |
| browser-errors-url | https://api.github.com/_private/browser/errors |
| release | 82560a55c6b2054555076f46e683151ee28a19bc |
| ui-target | full |
| theme-color | #1e2327 |
| color-scheme | light dark |
Links:
Viewport: width=device-width