Return to Revisions

Yes, it indeed appears as if the majority of the execution time goes into building the NativeArray with all the tile coordinates, while the job operating on said array only takes a tiny fraction of the computational time.

But that array does not even contain very useful data. It's really just a consecutive list of all the coordinate-pairs within a large rectangle. Some things you could try are:

• Don't parallelize per-tile, parallelize per-row. Create an array of the rows you want to check, and then have the Execute-function perform a for-loop over the tiles from start to beginning of the row. This still gives you 100 units of work for a 100x100 selection. Still more than enough granularity for letting the engine distribute the load on multiple cores in an efficient manner.
• Create a permanent NativeArray for all tiles on the map which you create once (Allocator.Persistent). Then use NativeSlices to tell the job system which tiles you want checked.
• Use another (non-parallel) job to build the UncheckedNodes NativeArray. A burst-compiled job might be able to do that more efficiently than regular C# code. Then schedule the ReallyToughParallelJob with the array-building job as a dependency.