Performance, consider inlining

[Bixilon]

You should consider inlining all variables like x in classes like Vec4i.

That will prevent wrapping values in classes like Integer, calculations are then done directly with the primitive type int. This speeds up performance and reduces memory usage A LOT!

[elect86]

Hi,

at first I had no idea what you meant, but this surfaced just right now..

which modifications do you suggest? I don't get why it gets boxed..

[Bixilon]

Okay, so making i clear (sorry);

All values like Int bet boxed at compile time to an Integer.

Its pretty simple, because e.g. Vec3t is using generics and has the "variable" T getX() defined. The problem is, hat generics do not exist at compile time, so it becomes Object getX(). ìnt is not an object, its a primitive, but Integer is a Number and that is an Object.

I solved it (because I don't really use Vec3t) and renamed that property to _x and Vec3 has x and override _x defined. Sure, that might break some stuff, at least in binary (recompiling of your own library needed) but also in source (changes in source code needed).

Also there is the index getter (T get(int index) that is just defined in the abstraction layer and thus not allowing proper inlining and creating a lot of unneeded object instanciation and performance bottlenecks in methods like equals.

I am not using stock glm anymore, because optimizing it myself without any review is quite nice. I am using my fork (https://gitlab.bixilon.de/bixilon/kotlin-glm).

I also changed some other things to make memory allocation not that heavy anymore:

• VecNt interface (no need to allocate parent class)
• inline all variables like x (one function call less)
• create more primitive constructors (like Vec3d from Vec3) without boxing
• create far more efficent empry constructors (like Vec3()), they are boxed too
• primitive short casts (see https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/e56f5171344171d786810a60a4369b6f88f928b4), that is a massive improvement merged
• a lot more, see commit history at gitlab (or comment below)

With all that changes, testing time (and that is mostly using String.substring, could be faster too, but not needed in praxis) got pretty much halfed and my game is running a lot faster as before and allocations are there down from 80MB/s to 5MB/s (along with other improvements ofc)

(ah and fogot: not my intention to make a PR, that would be far too heavy (around 10k lines), just letting you know)

[elect86]

Thanks for the nice valuable list: I'm gonna use that in the new multiplatform version, which uses code generation and make some of those things you listed incredible easy and fast to write

If you would like to partecipate, don't hesitate.

I can't keep up with all the things I'd like to implement in every library and in those I wish to write yet, so I'm leaning toward passive attitude, first accept and then review

I can send you an invitation right away. Also, I'm more than happy to donate some money for valuable PRs

[Bixilon]

which uses code generation and make some of those things you listed incredible easy and fast to write

That actually sounds really easy, I thought of that too, but was to lazy to create moritz-glm, I am ignoring most parts of glm, its simply "bloated" for my use.

I can't keep up with all the things I'd like to implement in every library and in those I wish to write yet, so I'm leaning toward passive attitude, first accept and then review

haha, I know that situation.

I can send you an invitation right away.

Nice chance, thanks fot the chance, I'd love to take it, but I think this is not the right thing. I am not the one who regularly commits to other projects. Sadly. My focus is and was always my game. My fork contains everything I need, feel free to grab it (cherry picking won't work, too bad I changed the namespace), its published under the same license.

Also I don't know how open you/the project is to backwards incompatible changes. I am. Shame on me.

Also, I'm more than happy to donate some money for valuable PRs

Yes. that honors me even more, but when I started that whole thing with nothing in mind (at least regarding money) and in my readme (https://gitlab.bixilon.de/bixilon/minosoft/-/blob/master/Contributing.md?plain=1#L25) there might be the line: Just doing it to learn stuff and have fun. I started this in mind, that I'll never earn money from it.. I don't know how much I can expand that to project only dependencies :)

I am not completely saying no, but don't expect much from me coming soon.

[elect86]

I'm not expecting regular commits at all, I know there are bursts and then silence, I'm like that :)

Also I don't know how open you/the project is to backwards incompatible changes. I am.

If it makes sense, then backward compatibility comes after in terms of priority.

Imho, backward compatibility is what kept java so behind.

I'll send you the invitation and if you have time and willness, you are more than welcome

[Bixilon]

So, I cherry picked some really easy commits that made pretty much no conflicts (and are not a complete hostile takeover).

I think the following changes are quite easy to adopt (still caused some conflicst); basic constrcutor optimisations:

• https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/0b57830430a91280dec378cd6e2af8a9fa77836c
• https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/7a9eee0b2bb2019513e3c38aea63afdf262c1708
• https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/22343d656f9fc0bf4e0aa830f0a9a21dab21a706
• https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/4cae94d070c6f27a8031ae6f79f31c9aab35e851
• https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/d60655b6e2eeda1703622ef22478d32aae23b6f1
• https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/3a0b1d3826b7f27cf5e02c4661d04fa421311977
• https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/4e77c1008be4084e48012e2dc2eb8c08eed44350 (actually broke the multiplication, fix https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/a490028ea13a7a8cda1fc64ac45520c2f30a00a9 needed too)

They should maybe be adopted, to reflect constructors of dear imgui, no clue what you use there and I have no intentions on using it. That could/should/will improve performance a lot (check in visualvm where Vec2, ... are allocated).

Those changes inline a lot of functions, use interfaces instead of abstract classes and (breakingly) remove the Vec1t components like xyz. That might break usage, dependencies, ... It is a MASSIVE improvement though.

• https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/c8f252ec5a2bc2311e57202374835f1641bb52b2 (pretty easy, just inlining a lot)
• https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/be015c709c970ed81e199daadb11dfe5355caca9 (reduce method calls; its dirty and not really the intention of kotlin getter and setter policy, but a minor improvement)
• https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/627a024618c7f3553b8f5d45f16e6098d7d5d96a, https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/101a89314fb55b3ecc9d575c52ee859318be8bbd, https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/b35f8b512fd09fe5d13dc30870f15db9c11d8b4c, https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/05f855ce853e3da2734e31d1c8d976b616ea49fb, https://gitlab.bixilon.de/bixilon/kotlin-glm/-/commit/05f855ce853e3da2734e31d1c8d976b616ea49fb (all 5 needed together, massive change)

[elect86]

I gave a quick look, they look fine by me

[Bixilon]

I started cherry picking in inlining-refactor-more...