Add FlxBuffer to hide Vector<Float> as a Array<T> #3192
Conversation
|
Pretty cool to see updates on this! Just make sure to not use typedefs structures stuff for the final thing since those are pretty slow compiling to dynamic |
I don't know what you mean by "pretty slow compiling to dynamic", typedefs compile crazy fast to non-static targets. the goal here is to have seemingly typed arrays/vectors without incurring any garbage collection from instances of the types I've done some initial tests and no types are actually used as everything is inlined away, see here: https://try.haxe.org/#ADa541d7 But I plan to do actual benchmark tests with these flixel classes, too |
|
In hxcpp (im not sure about other targets) typedefs compile has annonymous dynamic structures but yeah better to double check with benchmarks. |
Again I don't see why we're talking about compiling here, hxcpp takes me almost an hour to build from scratch, already and dynamic targets take an extra 10th of a second The benchmarks I'm referring to are for runtime performance because I don't see any concern for compile time. It sound like maybe you're actually referring to runtime performance but for some reason keep using the word "compile" |
|
@crowplexus and @NovaTheFurryDev, you voted thumbs down, care to share your concerns? |
|
removing the DV, my biggest concern with this was perhaps it being slower than the current method, I will definitely give this a try later on a blank project to see if it makes a major difference in comparison to the old method |
What's the DV? |
downvote or thumbs down |
| case TInst(local, [type]): | ||
| return buildBuffer(getFields(type, includeGetters), type, isVector); | ||
| default: | ||
| throw "Expected TInst"; |
There was a problem hiding this comment.
I think using Context.error() would be better than throwing since it shows the error at the location where TInst was expected
|
Is this a performance improvement thing or what? |
The goal is better readability and less human-error when maintaining or editing, at the hopes of not losing any performance |
I'd recommend switching from typedefs to classes for QuadRectRaw, QuadColorMult, and QuadColorOffset |
the typedefs are never instantiated, they are inlined away at compile time, as you can see in this screenshot of the completed todo item |
|
I tried this pr and the rendering was actually made slower than usual on hl |
I have no plans to merge this atm, I still need to check a billion things and there's more important things to do, but if perf is worsened it means this will not ever get merged. Also whenever you talk about performance it's always "i just ran it a bunch of times and it seems slower when I watched it". if you have an actual reproducible benchmark test, then share that, otherwise I'll assume you're just guessing |
The Problem
Many rendering systems are littered with
Array<Float>s meant to be used like so:and
This can be both hard to read and susceptible to human error compared to using
Array<FlxRect>, but not only does the current way greatly reduce objects that need to be garbage collected, many lime/open features specifically requireVector<Float>orArray<Float>, anywayThe Solution
FlxBufferandFlxBufferArray, under the hood they actually anArray<Float>orVector<Float>, but when writing code with them, you can easily deal with them as though they were anArray<{x:Float, y:Float}>. Truly the best of both worlds!The above code, while compiling to nearly identical source code, will look like this:
and
To Do
openfl.VectorvsArray