Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Potential Performance Issue Tracking

See original GitHub issue

Current potential performance issues in Nu, in no particular order -

Issue 1 - Event handlers in a dictionary are slower than handlers on the subscribed object a la C#. This means a look up for every publish. However, this is an artifact of a publisher-neutral event system rather than anything related to FP.

Possible Solution - A lot of optimization is already done to avoid publish calls that won’t have a useful effect. Beyond these, I have yet to think of further solutions.

Issue 2 - SDL2 rendering finally now batches sprites, yielding a 30% rendering improvement, but SDL rendering is still the clear bottleneck in Nu. FIXED.

Possible Solution - We need to write an OpenGL renderer from scratch whose context is instantiated on a separate thread. Hopefully the existing SDL text renderer can still be used from OpenGL since it renders to a texture rather than to an SDL back buffer.

Issue 3 - Farseer Physics Engine doesn’t scale to 1000s of interacting bodies -

Possible Solution - Presumably Farseer could be replaced with a much faster 2D physics lib, perhaps one written in C or C++. Of course, the question then becomes about the overhead of the required marshalling.

Issue 4 - Scripting language is purely interpreted, slowing it down by a couple orders of magnitude. MITIGATED: Scripting is no longer a primary way of using Nu - now you pretty much use Elm-style / MVU for everything.

Possible Solution - Partial dynamic compilation down to byte code would make the scripting language at least an order of magnitude faster. This is a lot of work, tho. Another alternative solution is the pseudo-compilation as described below.

Issue 5 - Much reflection used when creating / loading entities.

Possible Solution - Some of the reflection features during entity instantiation can be elided with the use of the NoOverlay case, but I think this might be taken further.

Issue 6 - Asset loading is still blocking.

Possible Solution - Put asset loading concurrent to the renderer.

Issue 7 - Stateful event streams like fold store all state in a dictionary, requiring look-ups. MITIGATED: Event streams are mostly replaced by the new Elmish programming model, so the impact of this should be reduced to the margins.

Possible Solution - Perhaps the event stream data could be cached in the key itself provided we can conceive of a working invalidation scheme.

Issue 8 - Engine is not yet compiling in .NET Native or Mono AOT. OBVIATED: It’s several months into 2020 and it looks like .NET native isn’t going to be a widely applicable solution for the general .NET ecosystem. Mono is also in many ways going away. We have to look to .NET Core and its capabilities for the future.

Possible Solution - I’m not sure if .NET native is ready for this type of project yet, but to solve this issue, we probably just need to put some time into it. This is just a matter of effort.

Issue 9 - Unfortunately, entire bitmaps are loaded just to get their metadata. This just needs fixed. FIXED (but not verifed)

Possible Solution - Need to find a .NET library that lets us inspect image metadata without instantiating the whole image buffer into memory.

Issue 10 - The string hashing required for each Xtension property look-up is suboptimal.

Possible Solution - Not many practical ones. This issue wouldn’t exist if C# lazy-cached hashes in strings, but there’s no reason to believe it ever will. At one point I used an alternative type to string called ‘Lun’ (later called ‘Name’) which contained a string and its eagerly-computed hash, but it wasn’t very friendly to use. I decided to get rid of it in favor of C# strings to simplify Nu’s API. I’m pretty sure this was the right decision, but I can’t prove it one way or another without making large speculative changes to the engine.

Update - Now that F# finally has implicit ctors, reintroducing the Name type shouldn’t cause as many changes as it previously would have. This might now be a practical experiment to run.

Issue 11 - ECS is relatively space-inefficient. The amount of memory for book-keeping required to store 3M correlated Vector2 components is almost an order of magnitude greater than the memory for the components themselves. Admittedly, a Vector2 is a very small component, but it would be nice for the ratio to not be so skewed. FIXED: with new ECS

Possible Solution - The primary issue with memory overhead is caused by nearly all component associations needing to be manually indexed. With Flecs, for example, this is unnecessary because of the way component associations are implicit in the archetype container and dynamically graphed for traversal. I don’t think this is possible in .NET without Unsafe mode code and / or code generation, neither of which is desirable in Nu.

Issue 12 - LOH threshold is perhaps too small.

Possible Solution - Upgrading to >= .NET 4.8 will allow us to configure it via GCLOHThreshold -

Issue 13 - Potentially a lot of events when a subscribed entity transforms -

Possible Solution - Probably nothing great. Could selectively disable a chunk of transform events depending on the application. Not real sure what to do here other than assess that this is part of the cost of doing business declaratively.

Issue 14 - Synchronizing entity properties via World.setEntityPropertyFast requires a small and likely cache-local dictionary look-up via WorldModuleEntity.EntitySetters, which is surprisingly fast.

Possible Solution - A faster alternative might be hard-coding a duplicate of the EntitySetters table in a match expression or using a loftier technique such as code generation in the MVU implementation.

Issue 15 - Nu Text rendering might be quite inefficient due to not caching target render buffers. IIRC, render buffers use for text are allocated and deallocated on a one-off basis. I do not see how that could possibly scale well.

Possible Solution - Code it properly. 😃

Issue Analytics

  • State:open
  • Created 7 years ago
  • Comments:11 (11 by maintainers)

github_iconTop GitHub Comments

bryaneddscommented, Jul 2, 2019

I’m currently working on putting the main subsystem processing on separate threads. If this works well, it should at least double performance.

bryaneddscommented, Jun 19, 2021

I was unable to utilize SDL_gpu due to this issue -

I don’t know if the maintainer, @grimfang4 is aware of the issue tho?

Read more comments on GitHub >

github_iconTop Results From Across the Web

15 Best Issue Tracking Software for 2023
Make it easy to manage, track, and resolve tickets, incidents, and problems with the best issue tracking software. Learn more in this guide....
Read more >
The 7 Best Issue Tracking Tools In 2023
Check out this list of the 7 best issue tracking tools in 2023. ... types of issues as well as overall performance metrics...
Read more >
Best Issue Tracking Software - 2023 Reviews & Comparison
Issue tracking software provides the tools to track, record, manage and follow the progress of issues and tickets in order to resolve problems...
Read more >
21 Best Issue Tracking Tools of 2023
The best issue tracking software streamlines project management by efficiently managing tasks, bugs, and customer requests.
Read more >
The 9 Best Issue Tracking Software Systems in 2022
Issue tracking software is a customer service and support tool that records incoming support cases from start to finish.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found