Merging two hash maps seems like an O(N) operation. However, while merging millions of keys, I encountered a massive >10x performance degradation unexpectedly. This post explores why some of the most popular libraries fall into this trap and how to fix it. The source code is available here.
| #include "context.h" | |
| #include "lib/thread_context.h" | |
| #include "lib/typedefs.h" | |
| #include "lib/string_builder.h" | |
| #include "os/os.h" | |
| #include "lib/math.h" | |
| #include "lib/hash.h" | |
| #include "lib/random.h" | |
| #include "gpu_backend.h" | |
| #include "renderer.h" |
| #ifndef MODERN_REF_HPP | |
| #define MODERN_REF_HPP | |
| #include <type_traits> | |
| #include <functional> | |
| #include <optional> | |
| #include <cassert> | |
| /** | |
| * @brief Ref<T> - A zero-overhead, nullable, rebindable smart reference. |
| # CMakeLists.txt project file for Raylib projects | |
| # | |
| cmake_minimum_required(VERSION 3.30) | |
| project(hello_raylib_with_cmake C) | |
| set(CMAKE_C_STANDARD 23) | |
| # Include the command that downloads libraries | |
| include(FetchContent) |
So you want to write a sync system for a web app with offline and realtime support? Good luck. You might find the following resources useful.
-
Database in a browser, a spec (Stepan Parunashvili)
What problem are we trying to solve with a sync system?
-
The web of tomorrow (Nikita Prokopov)
[EDIT: I've added a part 2 to this blog post, to address some of the feedback that has come up: https://gist.github.com/getify/706e5e10822a298375da40f9cc1fa295]
Recently, this article on "The JavaScript Block Statement" came out, and it received some good discussion in a reddit thread. But the general reaction seems to be against this approach. That saddens me.
—
Tauri is shipped with state management function/feature by default.
Basic usage is quite simple: a variable of State type can be accessed on the tauri commands which you have defined; in other words, "with tauri commands, they'll magically inject state for you," so that once a variable is managed you can inject them directly as additional input when defining the command.
| static ImGuiDockNodeFlags dockspace_flags = ImGuiDockNodeFlags_PassthruCentralNode; | |
| // We are using the ImGuiWindowFlags_NoDocking flag to make the parent window not dockable into, | |
| // because it would be confusing to have two docking targets within each others. | |
| ImGuiWindowFlags window_flags = ImGuiWindowFlags_MenuBar | ImGuiWindowFlags_NoDocking; | |
| ImGuiViewport* viewport = ImGui::GetMainViewport(); | |
| ImGui::SetNextWindowPos(viewport->Pos); | |
| ImGui::SetNextWindowSize(viewport->Size); | |
| ImGui::SetNextWindowViewport(viewport->ID); |
| static ImGuiDockNodeFlags dockspace_flags = ImGuiDockNodeFlags_PassthruCentralNode; | |
| // We are using the ImGuiWindowFlags_NoDocking flag to make the parent window not dockable into, | |
| // because it would be confusing to have two docking targets within each others. | |
| ImGuiWindowFlags window_flags = ImGuiWindowFlags_MenuBar | ImGuiWindowFlags_NoDocking; | |
| ImGuiViewport* viewport = ImGui::GetMainViewport(); | |
| ImGui::SetNextWindowPos(viewport->Pos); | |
| ImGui::SetNextWindowSize(viewport->Size); | |
| ImGui::SetNextWindowViewport(viewport->ID); |
