#GitHub - noaccessl/gmod-PhysicsCrashGuar...

1 messages · Page 1 of 1 (latest)

tardy plume
#

why use a 0 tick timer instead of think hook?

vocal minnow
#

i dont like it too
to make it better: push entity to queue & process it in next tick with GM:Think

austere steppe
vast meteor
tardy plume
vast meteor
#

Serverside, this is similar to GM:Think.

tardy plume
#

Called every frame. This will be the same as GM:Tick on the server when there is no lag, but will only be called once every processed server frame during lag.

See GM:Tick for a hook that runs every tick on both the client and server.

vast meteor
tardy plume
#

👍

vocal minnow
#

also "but will only be called once every processed server frame during lag" sounds nosence

austere steppe
#

This isn’t called every frame but shouldn’t https://wiki.facepunch.com/gmod/Vector:DistToSqr be used

vast meteor
#

No. It won't make a difference.

austere steppe
tardy plume
austere steppe
#

It’s not being called every frame but it’s still being called a lot

tardy plume
#

perf test it and prove it

#

wiki note aint proof

austere steppe
tardy plume
#

ive personally been unable to see any performance difference between them when i tested

austere steppe
#

I’ll test when I get home

vocal minnow
#

no need to test

tardy plume
#

prove it

vocal minnow
#

this is axiom

west lagoon
#
local numEntries = 1000000
local range = 100
local executionGap = 5 -- -1 to do it all in the same tick
local useDifferentData = true
local swapOrder = false

local entries = {}


local function generateEntries()
    for i = 1, numEntries do
        entries[i] = Vector( math.Rand( -range, range ), math.Rand( -range, range ), math.Rand( -range, range ) )
    end
end

local function doStuff1()
    local var
    local prevEntry = entries[1]

    for i = 2, numEntries do
        local entry = entries[i]

        var = prevEntry:Distance( entry )

        prevEntry = entry
    end
end

local function doStuff2()
    local var
    local prevEntry = entries[1]

    for i = 2, numEntries do
        local entry = entries[i]

        var = prevEntry:DistToSqr( entry )

        prevEntry = entry
    end
end

local function checkTime( stuff, name )
    local startTime = SysTime()
    stuff()
    local endTime = SysTime()

    local diff = endTime - startTime
    print( name .. " took " .. diff .. " seconds" )
    return diff
end


local function compareStuff()
    local methodName1 = "Method 1"
    local methodName2 = "Method 2"

    if swapOrder then
        doStuff1, doStuff2 = doStuff2, doStuff1
        methodName1 = "Method 2 (executed first)"
        methodName2 = "Method 1 (executed last)"
    end

    local time1 = checkTime( doStuff1, methodName1 )

    local function testTheRest()
        local time2 = checkTime( doStuff2, methodName2 )
        local timeDiff = math.abs( time2 - time1 )

        if time1 < time2 then
            print( methodName1 .. " was faster by " .. timeDiff .. " seconds!" )
            print( "This is an improvement of " .. math.Round( 100 * timeDiff / time2, 2 ) .. "%" )
        elseif time2 < time1 then
            print( methodName2 .. " was faster by " .. timeDiff .. " seconds!" )
            print( "This is an improvement of " .. math.Round( 100 * timeDiff / time1, 2 ) .. "%" )
        else
            print( "Both methods took the same time." )
        end
    end

    if useDifferentData then
        generateEntries()
    end

    if executionGap < 0 then
        testTheRest()
    else
        timer.Simple( executionGap, testTheRest )
    end
end


generateEntries()

timer.Simple( 5, compareStuff )
#

Running multiple tests each with and without executionGap, useDifferentData, and swapOrder ends up with inconsistent results that's easily skewed by execution order and delay.

With one million entries each, execution times ranged from around 0.9 to 0.12 and had improvement percentages of 0%-24%. This happened on both sides fairly evenly, determined by execution order more than anything else.

As far as I can tell, there's no significant performance difference between the two in gmod, despite sqrt algorithms being fundamentally slower in principle. Maybe the internal implementation doesn't actually skip the square root, or they're both so fast that it's negligible compared to the impact of cpu scheduling and the like?

This was tested on a 64bit dedicated server, and had similar results with/without jit.

#

Running it again with the distance lines commented out gives total method times around 0.0004 seconds, so reading the entry table had an insignificant impact.

Running again with var = entry.Distance and var = entr.DistToSqr instead gives times around 0.08, so roughly 10% of the total time is from accessing the distance functions without running them. It's less than the method's execution time, but still comparable in scale to the amount of variance observed.

#

Doing yet another test with math.Distance( x1, y1, x2, y2 ) and math.DistanceSqr( x1, y1, x2, y2 ) shows similar results; the two have very similar performance to one another, both sitting around 0.005 seconds for one million entries.

#

So, to reiterate, experimental tests appear to show that there is no significant performance difference between Vector:Distance() and Vector:DistToSqr()

smoky zephyr
#

@vast meteor threw this on my sever a couple days ago. It seems to prevent crashes but does some weird stuff like NPCs become transparent (resolve) and map moving objects like garage doors and even vehicles. Thought I would give you this feedback

vast meteor