Closed armadillu closed 6 years ago
Oh and doing this would would probably help reduce compile times #5731
I am supportive of changes that improve compile times / debugging / indexing and esp something like this which feels like it's not handicapping people too much (we never had swizzle before).
also there's another way to do swizzle using "glm/gtc/swizzle.hpp" :
https://glm.g-truc.net/0.9.2/api/a00002.html
might be less problematic?
Im finding Xcode debugging parts of code that have lots of
glm::vecX
objects (i.e. a vector of several hundreds ofglm::vec3
) almost impossible. When the debugger stops, Xcode tries to fill in the values for eachglm::vec3
object in scope and it takes several seconds for each one. This means every breakpoint leaves the debugger unresponsive for 40+ seconds in my case.I've been trying to reduce this lag by decrementing complexity in the glm::vec objects; I see GLM_FORCE_SWIZZLE implements tons of union data/structs, which seems to be part of the cause.
I've tried removing the
#define GLM_FORCE_SWIZZLE
fromofConstants.h
, which lead to lots of compile errors (basically each .xyz() or similar call). There's around 50 lines which rely on GLM_FORCE_SWIZZLE; I've changed them to not use the swizzle syntax, and I find the debugger much much faster, back to being usable basically.The changes (not from current master, from an older version July 10th 2017) can be seen here https://github.com/local-projects/openFrameworks/commit/d95f7d054267ccc0bec42b4eccf68d39c407909d
The overhead becomes obvious when printing a glm::vec3 object from lldb command line (sorry for massive scrolling, but I want to make the difference real clear);
Without #define GLM_FORCE_SWIZZLE
WITH #define GLM_FORCE_SWIZZLE
Should we think about dropping GLM_FORCE_SWIZZLE? It's nice to be able to use GLSL syntax on GLM, but the price to pay for this seems too high right now.
I haven't tested performance in other platforms.