HillaryKchao / ItuRPropagation.jl

A Julia implementation of the ITU-Recommendations for space links covering cloud, gaseous, rain, and scintillation attenuations.
MIT License
1 stars 1 forks source link

Speed Improvements #2

Open disberd opened 2 months ago

disberd commented 2 months ago

Hi @HillaryKchao,

Thanks a lot for creating this package! I noticed that the code here seems to be generating quite a number of allocations making this quite slower than it could be I believe, and definitely slower than the CNES C Library (now not maintained anymore) for also evaluating propagation impairments according to ITU.

I just forked your library as I wanted to try and remove allocation/speed up the code for our (work) internal simulations, and wanted to know whether you would be interested in getting pull requests in case I manage to improve the performance.

Ciao, Alberto

HillaryKchao commented 2 months ago

Hi @disberd,

Sincerest apologies for the delay in response - I've just started college, so I've been pretty busy.

I appreciate your input, and I'd love to have notification about pull requests you make! Please keep me updated.

Thanks, Hillary

disberd commented 1 month ago

Hey @HillaryKchao thanks for the reply!

I actually fixed all allocation in my fork of the repo and cleaned up a few more things to make the package faster both in loading and in executing.

I also decided to do a big breaking change to remove the various datasets from the git repository (as they are more than 100Mb of files that are downloaded with every clone and every different version of the package), putting it inside an artifact.

To really clean up the size of the repository I had to force push the deletion of these from the very first commit, so now my fork is completely different from this main repository (but mostly only due to this modification of the first commit).

How would you like to proceed? I am not even sure if it would be allowed to have a force push at the beginning for a package in the general registry, but if you are willing to have this I can try to ask in discourse or on slack on how to best proceed to avoid this big 100mb duplication for every clone of the repository.

Alternatively I can just propose the changes without modifying the project history, still migrating to artifacts but only deleting the datasets from the repo directly in later commits (this won't really avoid the huge size of the repository as the big files will still remain in the git history inside the .git folder).

HillaryKchao commented 1 month ago

Hi @disberd,

Perhaps keeping the size of the repository at a minimum would be best, but I honestly don't mind whichever path you choose to take. Please do whichever works best for you. :)

Thanks for keeping me updated! Hillary