Performance batch processing Messages

[eimfach]

I have the following edge case:

• I am generating large lists of data to create a world map for a game
• The generation process is batch processing a least 1000-1500 Messages but it can be way more depending on the world map size
• Since it would block the main thread if I would do it synchronously, I subscribed to Time.every 0 TakeMessageAndProccessIt to process each message (not animation frame , this would be too slow - 60fps only). It takes about 6 seconds to process about 1400 Messages, and I noticed that about 4 Seconds of it, it is idle ! I understand why there is idle time, but why is it so much ? Should I process multiple Messages in each step (Problem is also that some Messages in the Batch use Cmd with Random.generate ) ?

Here a small footprint of my Performance Profile:

Can you see the idle gaps ?
So my question is: Is there a way to make this better ? I also thought of a Web Worker to process this long calculations …

These are my messages for each field in the map: (Except DroppedGenerationDataForPerformance , SetCurrentEcoSystemType , SetBiomeList , EndStep )

type GenerationStepMsg
    = DroppedGenerationDataForPerformance
    | SetCurrentEcoSystemType EcoSystemType
    | SetBiomeList (List Biome)
    | RollRandomCoordinate (List WorldSpace -> Random.Generator Int) (List WorldSpace)
    | RollRandomBiome (List Biome -> Random.Generator Int)
    | RollChunkTreesSubCoordinates (List.Nonempty.Nonempty Tree -> Random.Generator (List ScreenSpace))
    | RollChunkTreeTypes (List.Nonempty.Nonempty Tree -> Random.Generator (List TreeType))
    | AddChunkToGlobalList
    | DropPickedBiomeFromBiomeList
    | CreateChunk (EcoSystemType -> Biome -> WorldSpace -> Chunk)
    | CalculatePossibleCoordinates (List Chunk -> List WorldSpace)
    | EndStep

[folkertdev]

So it seems likely here that messages don’t contain enough work, and the elm runtime has some maximum refresh rate.

How much of the messages are use Random? if that’s a lot, a possible partial solution is to keep track of the random seed manually, and use Random.step to synchronously get some randomness and continue processing without going through update.

[eimfach]

Wow, yeah that made a great speedup. Thanks a lot ! I refactored to Random.step and am now processing a batch of 50 messages per update: The time went from 6000ms to 150ms !

[joakin]

It may be worth mentioning that timeouts in the browser have a granularity of a few milliseconds. For some browsers it may be 4 or 1 but it is definitely not immediate.

window.requestIdleCallback and ports may be a better option for this.

[rupert]

@eimfach

Since it would block the main thread if I would do it synchronously, I subscribed to Time.every 0 TakeMessageAndProccessIt to process each message

Rather than susbscribing to Time.every 0 , just process some messages in your update then create a new Cmd to process some more. Use this code to create the messages:

Task.perform identity (Task.succeed TakeMessageAndProccessIt)

That will go faster (but still not 100% cpu), and allow the application to remain responsive. You can trade off responsiveness against larger batches of work - its not ideal and you will notice responsiveness suffer.

Something along these lines:

update msg model = 
    case msg of
        TakeMessageAndProcessIt ->
            case model.queue of
                [] -> (model, Cmd.none)
                _ -> (processNextBatch model
                     ,Task.perform identity (Task.succeed TakeMessageAndProccessIt))
        ...