profiled my mapper...

I’ve been working on a mapper for a while, and I decided to profile it. It was running a bit slow for my artist, and I must admit, it was a tad slow on my side as well. What I don’t understand is why this one function takes so long…

    Func          Func+Child           Hit
    Time   %         Time      %      Count  Function

81574.344 90.0 82778.525 91.3 6390 _glfwSwapBuffers (window.obj)
1304.838 1.4 1383.279 1.5 500627 Face: :Draw(float *,bool,bool,bool) (draws.obj)
1048.307 1.2 2139.781 2.4 19170 IsoView::Render(void) (views.obj)
991.989 1.1 1204.181 1.3 6390 _glfwPollEvents (window.obj)
859.491 0.9 859.491 0.9 105090 _glfDrawSolidSymbol (glf.obj)
479.685 0.5 7189.192 7.9 6390 Mapper::Render(void) (app.obj)
446.707 0.5 3036.337 3.4 6390 Camera::RenderScene(bool) (camera.obj)
208.510 0.2 227.089 0.3 38340 PicButton::Render(void) (window.obj)
208.510 0.2 227.089 0.3 38340 TexButton::Render(void) (window.obj)
208.510 0.2 227.089 0.3 38340 Tool::Render(void) (window.obj)
183.070 0.2 989.798 1.1 51881 Button::Render(void) (window.obj)
172.312 0.2 172.312 0.2 77082 Scrollbutton::Render(void) (otherwm.obj)
169.833 0.2 2332.329 2.6 75114 Prefab: :Draw(float *,bool,bool,bool) (draws.obj)
161.689 0.2 431.987 0.5 7904 Frustum::CalculateFrustum(class Portal *,struct Vector3,bool) (frustum.obj)
160.254 0.2 2465.494 2.7 75114 Mesh: :Draw(bool,bool) (draws.obj)
159.011 0.2 217.040 0.2 16548 ShinedLight: :DrawShadow(void) (shadow.obj)
152.312 0.2 3229.450 3.6 6390 PerspView::Render(void) (views.obj)
133.980 0.1 232.974 0.3 5799 __glfwWindowCallback@16 (win32_window.obj)
124.675 0.1 131.435 0.1 1 __glfwPlatformOpenWindow (win32_window.obj)
119.617 0.1 806.674 0.9 3439 Light: :Draw(void) (shadow.obj)
118.876 0.1 255.189 0.3 26123 Frustum::PolyInFrustum(class Portal *) (frustum.obj)
100.063 0.1 2121.024 2.3 66844 Sector: :Draw(bool,bool) (draws.obj)
91.651 0.1 91.651 0.1 440961 DynArray<struct Plane>: :operator[](int const &) (autoportal.obj)
83.128 0.1 942.619 1.0 18164 _DrawString (glf.obj)
79.748 0.1 79.748 0.1 288388 PolyInPlane(class Portal *,struct Plane) (3dmath.obj)
78.441 0.1 78.441 0.1 141863 Material::SetupDraw(void) (material.obj)
77.869 0.1 77.869 0.1 413084 Transform(struct Vector3,float *) (3dmath.obj)
63.131 0.1 1041.233 1.1 104085 Portal: :Draw(float *,bool,bool,bool) (draws.obj)
59.710 0.1 107.412 0.1 47340 Face: :planew(float *) (3dmath.obj)
55.510 0.1 920.451 1.0 54695 Font: :printf(int,int,char const *,…) (font.obj)
54.746 0.1 444.184 0.5 38541 Scrollbar::Render(void) (otherwm.obj)
45.655 0.1 45.655 0.1 38541 Sliderbutton::Render(void) (otherwm.obj)

Does this mean that my code is really well optimized?

[This message has been edited by 147-2 (edited 05-08-2003).]

This data is all relative to the app your running. The idea here is to pick out the routines which use the most cycles and optimize them. Performance comes down to fps.

Regards,
Jim

Originally posted by 147-2:
[b]I’ve been working on a mapper for a while, and I decided to profile it. It was running a bit slow for my artist, and I must admit, it was a tad slow on my side as well. What I don’t understand is why this one function takes so long…

    Func          Func+Child           Hit
    Time   %         Time      %      Count  Function[/b]

I first thought it would be the glfwPollEvents() function that ate the time, since glfwSwapBuffers() calls it, but as I found out when I looked closer at your list, glfwPollEvents() is taking way less than that.

Could it be some problem with VSync being enabled (try glfwSwapInterval(0))? But then, why isn’t _glfwPlatformSwapBuffers() in the list?

Im thinking something along those lines… I suppose it is not the profile that I should be concerned about, but what’s happening on the card which takes time. So therefore, when we go to swap buffers, the app has to wait for the vid card to catch up. I’ll have to look at glfwSwapBuffers again, and see if the platform’s glfwSB function shows up on the profile…
I just included the first handful of entries in my post. The actual profile list goes on for miles.

[This message has been edited by 147-2 (edited 05-09-2003).]