Profiling example

[rogerkuou]

Set up experiments for profiling, as required in https://github.com/TUDelftGeodesy/DePSI_group/issues/88

[Copilot]

Pull Request Overview

This PR sets up experiments for profiling the Arc Unwrapping algorithm using both loop‐based and Dask-based methods, as described in issue #88. Key changes include:

• Adding a Dask-based unwrapping implementation (both script and notebook versions) to leverage parallel processing.
• Including a loop-based unwrapping implementation (script and notebook) for baseline comparison.
• Updating documentation in the README to describe profiling procedures and commands.

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
profiling_example/lambda_unwrap_dask.py	Adds a Dask-based parallel unwrapping script with process‐based scheduling.
profiling_example/lambda_unwrap_dask.ipynb	Introduces a Jupyter notebook for debugging/visualizing the Dask-based implementation.
profiling_example/lambda.py	Provides a loop-based unwrapping script for direct unwrapping execution.
profiling_example/lambda.ipynb	Contains a notebook version of the loop-based unwrapping method for analysis.
profiling_example/README.md	Updates documentation to explain profiling experiments using both approaches.

[rogerkuou]

Hi @fnattino, in this PR I setup the profiling experiment.

The explaination of the files should be in README, including a link to the results. I put the discussion of the results in this discussion channel .

Can you review on the profiling method? Thanks

[fnattino]

Hi @rogerkuou, looks good! I think the instructions on how to setup the profiler are very clear.

Only very small suggestions from my side, the main one being that the pyspy-speedscope outputs are in JSON format.

With respect to the results of the benchmark, maybe it is not surprising that the Dask implementation essentially does not give any improvement.

The initial benchmark seems to suggest a lot of time is spent as overhead in small np call. With the for loop and most of the time being spent within the Python interpreter (i.e. not within numpy functions, which release the GIL) the threading approach cannot give any benefit. Not sure about the processing approach, but it probably suffers from the overhead of the data being transferred from the main process to the workers and back..

[rogerkuou]

Thanks @fnattino! I added your comments on the explaination to the discussion topic, and adapted your suggestions.