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

Imports take a long time #21

Open
ThirteenFish opened this issue Feb 26, 2024 · 2 comments
Open

Imports take a long time #21

ThirteenFish opened this issue Feb 26, 2024 · 2 comments

Comments

@ThirteenFish
Copy link
Contributor

Just imports, before we get to running any functional code, take a significant amount of the startup time for oresat-c3-software. I took a profile of imports during start-up with python3 -X importtime -m oresat_c3 on the C3. I've sorted the list by self time and cut it to only those that took longer than 100ms:

import time: self [us] | cumulative | imported package
import time:    101532 |     101532 |               werkzeug.routing.rules
import time:    101571 |     161549 |               spacepackets.cfdp.pdu.helper
import time:    102387 |     109682 |                     natsort.unicode_numbers
import time:    112929 |     124317 |                   pkg_resources.extern.packaging.version
import time:    114216 |     183644 |           spacepackets.ccsds.time.common
import time:    116643 |     425031 |       typing
import time:    117103 |     117103 |         yaml.resolver
import time:    118904 |     312051 |           click.core
import time:    125406 |     134787 |                   marshmallow.validate
import time:    137088 |     137088 |                 werkzeug.sansio.multipart
import time:    137676 |     182465 |           psutil._pslinux
import time:    137760 |     240675 |             ssl
import time:    153437 |     481512 |                 werkzeug.urls
import time:    183366 |     183366 |       oresat_configs.card_config
import time:    238623 |     238623 |         yaml.reader
import time:    245456 |    1699119 |   loguru
import time:    268458 |     274227 |         spacepackets.ccsds.spacepacket
import time:    286721 |     301695 |                   pkg_resources.extern.packaging.specifiers
import time:    366318 |     989058 |                   pkg_resources.extern.packaging.requirements
import time:    392257 |    3494041 |   olaf._internals.rest_api
import time:    560278 |     570939 |                       pkg_resources._vendor.pyparsing
import time:    606624 |     848651 |             natsort.natsort
import time:    765867 |     941800 |               can.interfaces
import time:   1623270 |    3427567 |                 pkg_resources

A lot of the long imports come from this project or oresat-configs. Looking at this list standouts from external packages are:

  • can.interfaces (pretty surprising, there's a lot of interfaces but we only need one. Can we prune it somehow?)
  • natsort
  • spacepackets
  • loguru
  • yaml
  • werkzeug

Do these have settings or optional features that can be cut out?

Things we control:

  • oresat_configs.card_config
  • olaf._internals.rest_api

Both of these files are very decorator heavy so maybe it's related to that?

I also don't know enough about pkg_resources to say what it's doing beyond it's stuff related to setuptools.

@ryanpdx
Copy link
Member

ryanpdx commented Mar 6, 2024

  • We need can.interfaces to support MacOS developers and for socketcand support which will become invaluable for ADCS Manager and the Task Scheduler.
  • We might be able to remove natsort (would have to review the code)
  • spacepackets is only used by the C3 app for EDL (not apart of OLAF). Cannot remove from the C3.
  • loguru could probably be replace with built in logging module
  • need yaml for oresat-configs
  • werkzeug is needed for the Flask REST API. But I was thinking of splitting the project into two modules/apps/daemons; OLAF and OLAF-REST-API, where there is a socket between them for IPC. Then Flask and it's dependencies wouldn't slow down the core OLAF app and could be disabled for flight, and we still get the REST API for integration, testing, and FlatSat.

@ryanpdx
Copy link
Member

ryanpdx commented Mar 7, 2024

Thinking about this more, we could easily replace the global logger object from loguru with an object of a custom wrapper class around the built-in logging module to avoid breaking the apps.

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

No branches or pull requests

2 participants