CrazyPython

time node --trace-opt --trace-deopt -e '
function bench() {
const loops = 3000;

const objSize = 4 * 3
const i32StartOffset = loops * objSize
const i32Size = 4 * 2
const ab = new ArrayBuffer(i32StartOffset + i32Size)
const f32 = new Float32Array(ab, 0)
const i32 = new Int32Array(ab, i32StartOffset)

CrazyPython

time node --trace-opt --trace-deopt -e '
function bench() {
const loops = 3000;

const objSize = 4 * 3
const i32StartOffset = loops * objSize
const i32Size = 4 * 2
const ab = new ArrayBuffer(i32StartOffset + i32Size)
const f32 = new Float32Array(ab, 0)
const i32 = new Int32Array(ab, i32StartOffset)

CrazyPython

A code chunk's lines of code must be in the same order you want them to be when the code is converted for the computer.

<<a>>=
console.log(foo)
@

<<a>>+
var foo = "bar"
@

CrazyPython

# An Introduction to Literate Programming, for "translators"

Start explaining how your Arras does *some area of technical expertise*, showing the code
behind what you're talking about as you explain. You must eventually use all
the code. Try to be logical in your explanation, for the sake of the human
reading it.  When you want to say that a particular chunk of code will be
defined and explained later and not show it now, use this syntax:

<<chunk name>>

CrazyPython

I want read-only access to your GitLab repository, with the permission to propose merge requests. Do that and I'll considering continuing staying on arras-dev.

If not, I'm gonna ask to join Fillygroove/Hellcat's server as a co-dev, and I'm gonna contribute my anti-lag efforts and my CTHD there.

I have three prongs of evidence that strongly lead me to believe that GC is the issue. And although I can't disprove the null hypothesis like you want me to, intuition trumps proof when you want speed.

Testing

We can do the Meausirng / Testing after you try out my fix in prod. But until then, it's not worth it for me to try to replicate your freeze-every-15-seconds behavior and do a controlled trial just to prove what my intuition already knows. Because I can't replicate your freeze-every-15-seconds behavior on my server by just adding lots of bots, and to do so I'd probably have to set up a VM (Or register for and wait for an OpenShift account.) with extremely limited memory size and allocate some swap to replic

CrazyPython

-march=native -mtune=native

CrazyPython

const { genericEntity } = require('../lib/basedefinitions.js')
module.exports.flag = {
    LABEL: 'Flag',
    ACCEPTS_SCORE: false,
    TYPE: 'flag',
    SHAPE: 6,
    PARENT: [genericEntity],
    SIZE: 50,
    DANGER: 0,
    BODY: {

CrazyPython

// gamemode files would be best in CoffeeScript
// real width is 3000
// food was originally 800, food would add an element of dodging
// this mode should have the leaderboard disabled on the client
// npm install driftless for more accurate timing
// also could npm install driftless help make arras faster, by maing gameloop execute more accurately?

exports.flagCarriers = []
exports.flagTimes = {[-1] /*blue*/: 5*60, [-3] /*red*/: 5*60}
const isFlag = e => e.type === 'flag'

CrazyPython

// GUN DEFINITIONS
const dfltskl = exports.dfltskl = 7;
exports.combineStats = function(arr) {
    try {
    // Build a blank array of the appropiate length
    let data = [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1];
    arr.forEach(function(component) {
        for (let i=0; i<data.length; i++) {
            data[i] = data[i] * component[i];
        }

CrazyPython

Benchmark notes

Putting the code within for (let j = 0; j < 100; j++) in its own function did not affect results in either benchmark. Removing this.x = 0; this.y = 0; did not affect results for the JS Array benchmark. Passing --trace-opt and --trace-deopt shows that the JIT optimizes all lines of code for both benchmarks in the first few iterations; it does not repeatedly try to re-optimize for either. The results scale. When passing j < 300, the JS Array takes 15-17 seconds while the Int8Array takes 0.54 seconds. That's a 27x performance improvement for a pure read/write/multiply ALU test.

More complex loop benchmark (if/else branch) Surprisingly, the Int8Array (now turned into a Float64Array) isn't just faster at loads and stores. Here's a floating point arithmetic benchmark (the code that's identical to the previous benchmark have been omitted):