Skip to content

[Ref] move static comparison out of hot TRACE path - #2591

Open
g5t wants to merge 2 commits into
mainfrom
2590-non-trivial-static-when
Open

[Ref] move static comparison out of hot TRACE path#2591
g5t wants to merge 2 commits into
mainfrom
2590-non-trivial-static-when

Conversation

@g5t

@g5t g5t commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Do not perform string comparison in WHEN statement

The comparison of a static string against a string valued instrument parameter is constant over the lifetime of a simulation.
Comparing it once per simulated ray is unnecessary and can be


Declaration of use of AI-tools

  • Please add a checkmark here if you used AI-tools during the work for this contribution
  • Furter, please describe how / where and for what the tools were used:

Development OS / boundary conditions

Linux


PR Checklist for contributing to McStas/McXtrace

For a coherent and useful contribution to McStas/McXtrace, please fill in relevant parts of the checklist:

  • My contribution includes patches to an existing component file

    • I have used the mcdoc utility and rendered a reasonable documentation page for the component (please attach as screenshot in comments!)
    • I have ensured that basic use of the component is OK (e.g. an instrument using it compiles?)
    • I have used the mctest utility to test one or more instruments making use of the component (please attach mcviewtest report as screenshot in comments)
    • I have used the mccode-clangformat tool to apply the standard McCode component indentation scheme
    • I have used the mcrun --c-lint "linter" and followed advice to remove most / all warnings that are raised
  • My contribution includes patches to an existing instrument file

    • I have used the mcdoc utility and rendered a reasonable documentation page for the instrument (please attach as screenshot in comments!)
    • I have used the mctest utility to test the instrument (please attach mcviewtest report as screenshot in comments)
    • I have used the mcrun --c-lint "linter" and followed advice to remove most / all warnings that are raised
  • My contribution includes a new component file

    • I have ensured that naming of parameters are in the style of existing components. (Please check the McStas or McXtrace NOMENCLATURE docs.)
    • I have ensured that component parameters are in the usually units of McStas or McXtrace (SI + neutron/x-ray 'usual' units)
    • I have used the mcdoc utility and rendered a reasonable documentation page for the component (please attach as screenshot in comments!)
    • I have ensured that basic use of the component is OK (e.g. an instrument using it compiles?)
    • I have included a corresponding example instrument and will fill in the new instrument section below
    • I have used the mccode-clangformat tool to apply the standard McCode component indentation scheme
    • My new component is added within the contrib component category
  • My contribution includes a new instrument file

    • I have used the mcdoc utility and rendered a reasonable documentation page for the instrument (please attach as screenshot in comments!)
    • I have ensured that basic use of the instrument is OK (e.g. it compiles?)
    • ... and provided reasonable default parameters in that instrument that produce reasonable output
    • ... and maybe even added a %Example: line to describe expected behaviour
    • I have used the mcrun --c-lint "linter" and followed advice to remove most / all warnings that are raised
    • My new instrument is added within the examples hierarchy in a folder in the style of examples/ESS/New_stuff/New_stuff.instr
    • My new instrument has a new, unique filename, not clashing with existing example instruments
    • My new instrument requires a data/input file. If the datafile is specific for my instrument I have left it in the same example folder, but if general use I have placed it in the global data folder.
  • My work touches the code-generator in mccode/src

    • I have added reasoning and documentation for the change through an ADR record in our GRAMMAR section
    • I am attaching test output in the comments
  • My work touches / adds to the runtime lib code (.c,.h etc in multiple locations

    • I am have added reasoning and documentation for the change below
    • I am attaching test output in the comments
  • My PR is meant to fix a specific, existing issue

    • I have indicated the issue number here:
    • I have added documentation for the fix and possible side effects
  • My contribution contains something else

    • Explanation is added in free form text above or below the checklist

Fixes #2590

@g5t g5t linked an issue Aug 7, 2026 that may be closed by this pull request
@g5t

g5t commented Aug 7, 2026

Copy link
Copy Markdown
Contributor Author

I'm not uploading screenshots because

  1. mcdoc output is unchanged
  2. mctest passed but mcviewtest fails on line 254, iterate_obj_to_populate_rows 🤷

@g5t
g5t requested a review from willend August 7, 2026 13:34
@willend

willend commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

@g5t it’s admittedly not so well documented but but we have #define NAME_INSTRUMENT (instrument->_name) that can be used in the instrument scope in place of NAME_CURRENT_COMP

@willend

willend commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

I'm not uploading screenshots because

mcdoc output is unchanged
mctest passed but mcviewtest fails on line 254, iterate_obj_to_populate_rows 🤷

@g5t this is fair. Point me to the test artifects and I might have a look early next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Static non-trivial WHEN statements should not be evaulated in TRACE

2 participants