Skip to content
This repository has been archived by the owner on Oct 23, 2022. It is now read-only.

Poor performance of ray generation in Emitters.jl because of abstract struct field #208

Merged
merged 3 commits into from
Jun 25, 2021

Conversation

BrianGun
Copy link
Contributor

@BrianGun BrianGun commented Jun 24, 2021

Description

Fixes # 207 Poor performance of ray generation in

Changed Integer to Int64 in struct field declarations in Emitters code. The previous declaration was causing allocations and slow execution.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

ran unit tests

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules
  • I have checked my code and corrected any misspellings

… struct field

Fixes #207

Changed all Integer declarations to Int64 in Emitters code. Allocations for all ray generation functions are now 0 bytes. Speed is greatly increased.

Also removed functions HOE, reflgrating, grating from other_examples.jl because they had old non-functioning code.
@BrianGun BrianGun requested a review from galran June 24, 2021 21:40
@codecov-commenter
Copy link

codecov-commenter commented Jun 24, 2021

Codecov Report

Merging #208 (430eb32) into main (9eec4c4) will increase coverage by 0.16%.
The diff coverage is 90.32%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #208      +/-   ##
==========================================
+ Coverage   56.41%   56.58%   +0.16%     
==========================================
  Files          67       67              
  Lines        6388     6366      -22     
==========================================
- Hits         3604     3602       -2     
+ Misses       2784     2764      -20     
Impacted Files Coverage Δ
src/Examples/other_examples.jl 1.78% <ø> (+0.28%) ⬆️
src/Optical/Emitters/Spectrum.jl 17.07% <0.00%> (ø)
src/Optical/Emitters/Sources.jl 95.89% <87.50%> (ø)
src/Optical/Emitters/Directions.jl 100.00% <100.00%> (ø)
src/Optical/Emitters/Origins.jl 100.00% <100.00%> (ø)
src/Optical/OpticalRay.jl 62.06% <0.00%> (-1.27%) ⬇️
src/Optical/OpticalSystem.jl 39.87% <0.00%> (-0.32%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9eec4c4...430eb32. Read the comment docs.

Project.toml Outdated
@@ -5,6 +5,7 @@ repository = "https://github.com/microsoft/OpticSim.jl"
version = "0.5.1"

[deps]
BenchmarkTools = "6e4b80f9-dd63-53aa-95a3-0cdb28fa8baf"
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think BenchmarkTools should be a dependency of the package itself - it's already installed separately for tests

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See comment below.

@@ -254,34 +254,6 @@ function fresnel(convex = true; kwargs...)
Vis.drawtracerays(sys; test = true, trackallrays = true, numdivisions = 30, kwargs...)
end

function grating(; period = 1.0, θ = 0.0, λ = 0.55, kwargs...)
Copy link
Collaborator

Choose a reason for hiding this comment

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

These removals seem unrelated to the PR - is this intentional? If so maybe should be a separate PR

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was intentional. A separate PR would be better in an ideal world but because it was a deletion of code that didn't work anymore it was simpler to add it into a single PR.


### Emitters

function RectGridAllocations()
Copy link
Collaborator

Choose a reason for hiding this comment

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

100% agree on adding a test for Emitter allocations to ensure this kind of regression doesn't happen again - but it should really go in Benchmarks.jl and be added to all_benchmarks which will then be tested as part of the allocations tests

@@ -6,6 +6,7 @@ using Test
using OpticSim
using OpticSim.Emitters
using OpticSim.Geometry
using BenchmarkTools
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think this is needed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, that was an accident. I put it in temporarily because it was much faster to verify that the fixes were working than running the test set.

This is a weakness of our current setup. There are many times when you need to run a quick test like this, when you are first debugging the code. If this is done in the test sets then it's a 5 minute cycle as opposed to a few seconds if BenchmarkTools is a dependency.

I'll remove the BenchmarkTools dependency for now.

galran
galran previously approved these changes Jun 25, 2021
… struct field

Fixes #207

removed BenchmarkTools dependency from OpticSim.
@BrianGun BrianGun merged commit 0f9012b into main Jun 25, 2021
@BrianGun BrianGun deleted the BrianGun/issue207 branch June 25, 2021 18:44
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants