Open mosra opened 6 years ago
Progress!
Corrade/Utility/TypeTraits.h
got simplified in mosra/corrade@9b258d768f5c17f5dd79a71d61d86187b18f223dUtility::Directory
is iostreams-free since mosra/corrade@c1a5eedc039a2d7479a8a947ecd2d6985524cb55Containers::Pointer
and Containers::Reference
implemented in mosra/corrade@4e7195739acd43eb8b0bc12c229ff573f47cf355 and mosra/corrade@a874478917854cdfa7a4bcc996ba829c2c39ada2, STL compatibility for them and Optional in mosra/corrade@b9f52d413eec2ddbea6c7b0dd2bf34c5d1ca27b0, mosra/corrade@80ef819bb96a752eaa05030cbb6b6541c882dcf7 and mosra/corrade@69e6593f830c37d0247c0cd57ca5bfbcf0b9987bPlatform::EmscriptenApplication
is in-progress in #300Text
doesn't have a hard dependency on GL since 834c5fe40d01499755b8281c667a7402ca94583e, all plugins now build on CI completely GL-less since mosra/magnum-plugins@e6f879206e24ded0e5d5bdce6f122ad4f81ca546Debug
since mosra/corrade@64c56aa1196f8f49a1d967a7689720e0b594197a (used mainly for the magnum-singles repo)More progress:
See above for the actual commit references.
For the 2018.1d release (and onwards) I'd like to focus on reducing the header and executable size, together with improving compile time (and, as a side effect, runtime performance). This was last done in 2013 (see the blog article) and while current workflow enforces enough rules to prevent worsening of this problem, it's not actively improving it either.
The ultimate goal is being able to ship useful utilities as "single-header" libraries
without being laughed at for compile timesand having compile times competitive with C header-only libs, yet staying in C++. Which, of course, means much better compile times than other C++ projects (json.hpp and Eigen, I'm looking at you).Compile time improvements
Add (and start using)#pragma once
in all headers, as it leads to measurable compile time improvementCORRADE_TARGET_LIBCXX
/CORRADE_TARGET_LIBSTDCXX
macro that tells me whether libc++ or libstdc++ is used (needed by the things below) -- detection using<ciso646>
and _LIBCPP_VERSION, https://stackoverflow.com/questions/31657499/how-to-detect-stdlib-libc-in-the-preprocessor, there needs to be an exception for GCC < 6.1: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65473 (and a TODO to use<version>
in C++20) -- mosra/corrade@b6b37fbd2150879d47e18fb9ba115e52ea6551a4std::string
-- mosra/corrade@2345195d5daf704d628a2a7db9ff4ad1dcc977da<xstring>
, ruling out any forward declarationstd::vector
-- mosra/corrade@2345195d5daf704d628a2a7db9ff4ad1dcc977daanything in libstdc++?nope<vector>
, which rules out any forward declarationsUtility::Arguments
,Utility::Configuration
Text::Renderer
andText::AbstractFontConverter
APIsAudio
librarygoing to be put to maintenance mode, not neededSceneGraph
Provide (and use) a header wrapping platform-specific forward-declaration headers forusing our ownstd::reference_wrapper
because<functional>
alone is 22k lines (and grows to 44k in C++17, WTAF!!)Containers::Reference
instead<type_traits>
on libstdc++, libc++ and MSVC STL as well (there it has a full definition, yay)std::tuple
(<tuple>
is >20k lines on libstdc++) -- mosra/corrade@2345195d5daf704d628a2a7db9ff4ad1dcc977da<type_traits>
on libstdc++<utility>
on MSVC STL, defined next tostd::pair
Containers::Pair
/Containers::Triple
/ custom structs in all internals and APIs, keep only in STL compatibility headersDebug.h
toDebugStl.h
Text::AbstractFontConverter
Animation
APIsdataProperties()
(ditch all that, use strided array views)going to be put to maintenance mode, not neededSceneGraph
doesnope, but we havestd::pair
have a forward declaration somewhere? though<utility>
is just 4k linesContainers::Pair
now<array>
is also big (~20k) but we're not really using it in public APIs -- yes, mosra/corrade@fd8030d93d7abe595e50dba6251d9cd4e9779c03<iterator>
that's needed only forstd::begin()
in libc++, it's quite big so include it conditionally only for libc++ -- mosra/corrade@9b258d768f5c17f5dd79a71d61d86187b18f223d<utility>
, is it needed?decay()
is in<type_traits>
already -- mosra/corrade@9b258d768f5c17f5dd79a71d61d86187b18f223d<algorithm>
just to havestd::min()
for scalars on MSVC -- mosra/corrade@1719c57d6f7e0d9174e7f0c46c906ee2c40f084a, 563dee0436166556cb26af79a49cc380af7a9cd1<map>
,<unordered_map>
and other huge containers from headers, PIMPL these (no, I'm not going to implement them myself just yet) -- it's justInterconnect
andText
libraries left, which need a significant cleanup anyway<algorithm>
there -- mosra/corrade@1719c57d6f7e0d9174e7f0c46c906ee2c40f084astd::unique_ptr
andstd::reference_wrapper
-- mosra/corrade@4e7195739acd43eb8b0bc12c229ff573f47cf355 and mosra/corrade@a874478917854cdfa7a4bcc996ba829c2c39ada2<cmath>
in C++17: https://twitter.com/czmosra/status/1085993965529255936 -- mosra/corrade@115b56eb74665a0570d68fc31d9bc28e9015f319Look into https://github.com/RPGillespie6/fastcov to have faster coverage buildsno longer needed, lcov 2.0 is fast enoughInvestigate opting intoconverted to a O(log n) implementation in mosra/corrade@0b828147d692a472846dad16f730bc0d844886b7, which should be good enough__make_integer_seq
compiler builtins instead of our own GenerateSequence, might have a significant effect on build times especially with long vectors, large matrices or constexpr constructors of the new MaterialData (#459) -- https://reviews.llvm.org/rL252036Executable size reduction / perf improvements (mainly WebAssembly-focused)
-Wglobal-constructors -Wexit-time-destructors
on ClangGL::defaultFramebuffer
,GL::Context
-- b05c88737510cb9afd01c5c65ece2b1251abb7c2-Oz
with Emscripten, switch the toolchains to that, fix Emscripten closure compiler (https://github.com/mosra/magnum/issues/211) and investigate how much can it shave off the JS code (around 200 kB?) -- mentioned in the docs as of df6b414185c649d0adf58c81e4859197cd81fae2, not enabling by default since it has compile time impactSome preprocessor hook forstrip license headers off shader sourcesUtility::Resource
that's able toMinifierShaderConverter
std::sort()
replaced with a counting sort, saving ~8 kB -- e96996ea0169c6df860ff967ebb242da746825c4std::unordered_map
replaced with hand-sorted compile-time array, saving ~8 kB -- 54c42dfb4dc37763d8f8c1dc7772268d6bcb5bd4, e2621fac3cf2c9b74c822b3a62d6306fcd7ae77d-s FILESYSTEM=0
(compile away parts ofUtility::Directory
,GL::Shader::addFile()
, non-callback-basedTrade::AbstractImporter::openFile()
etc.Bigger tasks
std::cout
adds 250 kB to JS + WASM size) -- depends on string/stringview classesUtility::format()
-- app usingstd::printf()
has only 40 kB compared to thatUtility::Debug
classUtility::Directory
-- mosra/corrade@c1a5eedc039a2d7479a8a947ecd2d6985524cb55Utility::format()
without printf (float conversion with Ryū, integer conversion using "the fastest ever integer conversion" as claimed by the author of fmt) -- float32 tables in Ryū are 624 B and even float64 tables in Ryū are just 10 kB and withUtility::format()
if we don't print doubles, the tables won't even get compiled inprintf()
-- a naive copypasted implementation using grisu3 was just 25 kB, shaving > 10 kB compared to printf (and being much faster)abort_handler()
, patch emscripten to not do thatEmscriptenApplication
instead of usingSdl2Application
-- should trim down at least the generated*.js
file size (thelibrary_sdl.js
is 137 kB (though unminified)) #300tiny_gltf might be going away from json.hpp on its own (https://github.com/syoyo/tinygltf/issues/141)just the TinyGltfImporter plugin compilation alone takes around 15 seconds -- for a single file -- which is more than all other plugins combinedI bet it has some effect on WASM output size as well, just don't know how muchText
library by creating an abstract API-independent base for glyph cache -- 834c5fe40d01499755b8281c667a7402ca94583eCORRADE_ASSERT
to the Cassert
) -- needed for the single-header libs, done in mosra/corrade@64c56aa1196f8f49a1d967a7689720e0b594197a and cee530733ea43e480dbe782f2fb1358257710750#include <DebugStl.h>
to be able to print STL typesCI speedup
ci.magnum.graphics
some token authentication so it's not publicly accessible (just restricting to Travis/AppVeyor IPs is not enough, as we want to prevent mainly CI users from abusing the server)turned out to not be a problem in practiceLong-term
Containers::Array
so we can ditchstd::vector
as a growable storage, eliminating it from headers completely -- mosra/corrade@3cf41e3897d3558416d52e22dcd6c84f0d34e73c and followingarrayRemoveUnordered()
as well -- mosra/corrade@c9089f71b7c927add9cefe76d036d51acb4f534aconst char*
/const char(&)[n]
/const std::string&
overloads everywhere, again eliminatingstd::string
from headers completely -- mosra/corrade@72f652d22584534492a95743266e26a48bdb684dString
class as well, with small string optimization (https://wg21.link/P1330, chapter 4) and easily convertible from/to the string view -- mosra/corrade@64f583602d1d18d8f5182e65fc565a6d964f4607Utility::String
to use it in progressUtility::format()
work with it -- mosra/corrade@ea9f21790ff88e47a4e0d830165315ecf15644e9formatString()
toFormatStl.h
-- mosra/corrade@e941c843b3e2255f59e974d4c0b583c48b9238cbUtility::Arguments
,Utility::Configuration
Audio
APIsText::Renderer
,Text::AbstractFontConverter
StringStl.h
includes once enough time passesFurther work
Investigate compiling with a lighter-weight STL implementation (e.g. nanostl, EASTL?) -- most of them have no type_traits, we need type_traitsnot happening, at this point it's easier to just ditch the remaining use of STL altogether and rely on compiler-specific builtinsCan C++20(?) modules help in any way with compile times? So far I didn't see any experiment that would prove a breakthrough in compile times-- probably notThe Utility/Debug.h headers will be still quite heavy after forward-declaring strings and removingno it's not, it's fine since mosra/corrade@89da382496fb84c12fa4e2ece7bbea8f9721a191 (just<iterator>
and since these get used almost everywhere, what to do?<utility>
and<type_traits>
)Further read / references: