Strange profiler results depending of events order

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Hi,

    I get strange results with profiler where events times seem to depend of their order in the code.

    You will find attached an example showing what I'm talking.

    All started when I wanted to compare performances of differents solutions to get distances between 2 points.
    I globally have 4 ways :
    - make use of the math formula : square of ((X1-X2)^2+(Y1-Y2)^2)
    - use the "ODistance" built in function
    - use Advanced Direction Object (long & float values)

    So I made a simple frame with 2 objects bouncing around the screen.
    On each main loop, I use 4 counters to calculate the distance between these 2 objects with the 4 different solutions.
    Then I use profiler to get time of each event.

    On first test I get :
    - counter 1 (ODistance) = 4,365 ms (26,78%)
    - counter 2 (Advanced direction object with long value) : 1,954 ms (11,99%)
    - counter 3 (Advanced direction object with float value) : 6,008 ms (36,87%)
    - counter 4 (math formula) : 2,706 ms (16,60%)

    According to this test, the fatest option is Advanced Direction Object with long value with only 1,954 ms. The second fatest solution is the math formula.
    This result is consistent : I get the same result each time I make a test.

    But if I change the order of events, for example :
    - counter 4 (math formula)
    - counter 2 (Advanced direction object with long value)
    - counter 3 (Advanced direction object with float value)
    - counter 1 (ODistance)

    Then I get these results :
    - counter 4 (math formula) : 11,590 ms (69,30%)
    - counter 2 (Advanced direction object with long value) : 2,010 ms (12,01%)
    - counter 3 (Advanced direction object with float value) : 1,113 ms (6,65%)
    - counter 1 (ODistance) : 0,771 ms (4,61%)

    This time, the fatest option is ODistance, then ADO with float value.

    In fact, according to my test : profiler results seem to partially depend of the order of the events.

    So, my question is : is there an exaplanation or is it some sort of bug in the profiler ?

    I confirm it, there might be several explanations to this:

    1. there might be a penalty for the first non-true event or if the profiler needs to reallocate things, I'm not sure though, I've to check the code, maybe we can improve this part though iirc it was quite clean. Maybe add a line before those 4 lines?
    2. your actions are very simple, there might be some imprecision issues due to time taken by the main loop. You should duplicate 10 or 20 times each action to increase the time they take comparatively to the "fixed" time taken by each line.
    3. IIRC the event data are not all aligned on a 4-byte boundaries, and this may depend on the size of the previous event line, I think this can cause performance penalties in some cases, this could perhaps explain a part of the difference. I'm not 200% sure though and if it's the case then it probably has an effect only on very simple event lines like yours. I think we can't change this due to some extensions accessing event data (I'll check anyway, maybe we can change the alignment of each line even if we can't change the alignment of everything).

    Edited 2 times, last by Yves (November 9, 2022 at 10:56 AM).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login