Nativecardis in the Sales Force Automation Industry

Nativecard

Web3, DAO, DeFi, and cryptocurrencies have all generated a lot of hype and excitement in the digital world, but their adoption hasn't been as extensive as expected. This has become a troublesome question for many tech experts. Despite decentralized technology being embedded with robust AI and machine learning, it's still difficult to hack, but people are still resistant to its adoption. The main culprits behind this are technology issues, user difficulties, and high entry fees. For example, to access web3 platforms, users need to sign in to a crypto wallet, which can be a challenging process, both in terms of selecting a crypto wallet and making transactions from it. In addition, interacting with dAPPs on the Ethereum network (Layer-1) can be incredibly expensive and difficult. Investors have to pay a significant portion of their investment in the form of gas fees, which can range from 10-15% of the total transfer amount, making it impractical for many users. Apart from these issues, the new technology is quite confusing and risky, even though the masses are aware of its potential benefits. The difficulty of learning or managing the private key and performing transactions beyond their comfort level hinders the broader adoption of this technology. When it comes to sending or receiving cryptocurrency, people always look for the ease and convenience of sending a text message. Therefore, web3 development companies are focusing on building customer-focused projects every day and coming up with something new that is both trustworthy and simple to use. However, these companies are still in their pioneering stages. Problems of Poor User Experience that Are Holding Back Web3 Adoption Private Key Management Poses a Problem in Crypto A crypto wallet is at the core of all transactions, from sending cryptocurrency and managing accounts to minting NFTs and bridging USDC from Optimism to Arbitrum. It holds everything you own and enables you to interact with the network. However, all accounts are not created equal and can vary based on EOAs (Externally Owned Accounts) or Contract Wallets. Most users' accounts fall under the EOA type, and this is where the first web3 UX problem arises. EOA accounts are identified by a 42-character string of numbers and letters prefixed with "0x," known as a private key. The biggest challenge is remembering all the private keys, which is the sole responsibility of end-users. If a single digit is missed, the account becomes inaccessible. Unlike web2 platforms where users can click on "forgot password" and generate a new password using their mobile and email ID, web3 doesn't offer any password recovery. Web3 Moving Away From Recovery Phrases Many web3 developers are working on the recovery phase to address this issue effectively. Vitalik Buterin advocates for sharing something on social recovery wallets that don't require recovery phrases. The concept requires many promises as more work needs to be done to make it more user-friendly. dApps Require Too Much Onboarding Every interaction on Ethereum-based platforms involves gas fees to complete transactions. We cannot assume that non-crypto natives without prior Web3 exposure or knowledge of blockchain transactions can convert fiat to crypto, buy/swap assets for ETH, pay for gas fees, and sign off on transactions correctly as they onboard dApps. Gas Fees Can Only Be Paid In Native Assets Needing native assets to pay for gas fees is another significant hurdle. Swapping tokens and bridges to cover the fees is tedious and time-consuming. Users Have To Execute A Transaction For Every On-Chain Interaction Completing one transaction at a time is a time-consuming and frustrating process for individuals. Moreover, it involves additional minting, gas fees, and other charges too. This is something every user wants to avoid in a fast-paced world. Many blockchain technologies claim to overcome this issue, but only a select few can cope with it. Lack Of On-Chain, Cross-Chain Interoperability Most Web3 projects are siloed, and users must navigate multiple frontends, bridge UIs, and submit repeated transactions to buy and sell assets between networks. Market segmentation also comes with its own costs, introducing a new class of complex product questions that are still not widely adopted by many. Their users often find obstacles in choosing which cross-chain operations to use and which assets they can use them for. What do Users Want from Web3? People Want Convenience People desire a platform that is quick and easy to use, allowing them to accomplish their objectives more rapidly and inexpensively. If we examine the current web3 projects, many appear to be designed for engineers by engineers. The complexity extends beyond the service itself, with whitepapers filled with technical jargon that most new users will never comprehend. Those who persist in sifting through jargon-filled explanations are currently navigating the complex user journey of web3 platforms. If web3 platforms aspire to become mainstream and supplant web2 platforms, they must simplify everything. Designing friction needs to be minimized to welcome those who lack technical proficiency. Greater emphasis should be placed on those who did not grow up with mobile phones and video games. A simple interface is sufficient for them. More Familiarity With Ramps We all understand that web3 and blockchain are still novel concepts for many individuals. Brands like and are striving to simplify engagement in the sector by utilizing browser extensions. These extensions are designed to provide new users with simplified sign-in alternatives and hassle-free on-ramps to new projects. MetaMask Coinbase Wallet However, obtaining a wallet can be a difficult task for many individuals. To recover digital assets, users must safeguard the seed phrase. Otherwise, you will have a difficult time recovering your digital assets, which is prevalent since many people are unfamiliar with the technical aspects of blockchain. If someone manages to keep their wallet secure, there are still many stages involved in converting crypto assets into something they can use in their daily life. Users frequently employ third-party intermediary applications to convert cryptocurrency into native currency to pay their bills. As a result, people seek on and off-ramp solutions to become more familiar with platforms. web3 Financial Off-ramps One of the most significant disadvantages of web3 technologies is their limited adoption in many prominent locations. Crypto is rarely accepted outside web3-specific services as a means of payment, leaving few options for users to purchase anything using crypto. Users frequently need to return to their fiat currency, which is a difficult process to reverse. Suppose you have $1200 worth of in your wallet and need to pay a utility bill of $950. The remaining balance must be converted back into native currency. You would likely follow these steps: Ethereum Log in to the crypto exchange. Sync your wallet; Add your funds from the ethereum wallet to the exchange wallet. Exchange your ETH into native currency by paying gas fees. Once the exchange converts cryptocurrency to native currency, it's time to withdraw USD to your bank for yet another fee. Every time users need to convert from or crypto to fiat, they must pay a significant fee, such as a gas fee. As a result, users spend a significant amount of time and money converting to and from cryptos. Many players are focused on simplifying the process, but it is still in the early stages and will take a significant amount of time. fiat to crypto If the process becomes faster and simpler, more crypto transactions are likely to occur, potentially creating a revenue-generating business environment. Potential fixes There should be more focus on creating crypto exchanges crypto exchanges that are integrated within an app, or by using white-label solutions that offer institutional services at a lower fee. By integrating crypto exchanges with other payment solutions, users can pay using their Coinbase debit card or leverage to enable on and off-ramps on the platform, making transactions seamless. MoonPay Seamless Transactions There are two major issues with blockchain transactions: addresses and the way transactions are processed. First of all, check my public Ethereum address 0xa3f3076e33d36e6f1572f78c868bc0115a896a8c5e51ff7cab8396e5e1ff14961 You might be thinking it's a typo. Indeed it’s not. If someone wants to send me something, I have to give them my complete address. Addresses are long, complicated hashes that can be difficult to remember or verify. To send or receive currency, one must input the full address without any mistakes. A single error can send assets to the wrong address, with no way to retrieve them. The long hashes also look terrible, especially when you are trying to figure out who is sending you something and when. Another issue - the way transactions are processed Most dAPPs require users to sign agreements at every stage of a transaction, which can be time-consuming and cumbersome. Think about how you will feel when a platform orders you to click “agree” before proceeding. It could be a daunting task as it takes longer time to do things and requires too much attention from users. Here’s Hasu defining the transaction process graphically. How to fix it? Roll out services like ENS Domains where abstract addresses can be transformed, which are easy to remember. These could be phrases or else. Reduce a load of multiple checks on users as a single step can roll out approval. Today’s Problems Are Tomorrow’s Opportunities The major cause of poor user experience is the early nature of the tech that holds back its adoption. Best Web3 Development tech experts are working to solve them and make the entire ecosystem more user-friendly. Therefore, tech experts are considering these problems as a catalyst that grows tomorrow’s most impactful businesses.

How Poor User Experience is Holding Back Web3 Adoption

The Koinos Blockchain Whitepaper: Evolving Framework With Modular Upgradeability and Governance 

Unity DOTS allows developers to use the full potential of modern processors and deliver highly optimized, efficient games – and we think it’s worth paying attention to. It’s been over five years since Unity first announced development of their Data-Oriented Technology Stack (DOTS). Now, with the release of Unity 2023.3.0f1, we’ve finally seen an official release. But why is Unity DOTS so critical to the game development industry, and what advantages does this technology offer? Hello, everyone! My name is Denis Kondratev, and I'm a Developer at MY.GAMES. If you've been eager to understand what Unity DOTS is and whether it's worth exploring, this is the perfect opportunity to delve into this fascinating topic, and in this article – we’ll do just that. Unity What is the Entity Component System (ECS)? At its core, DOTS implements the Entity Component System (ECS) architectural pattern. To simplify this concept, let’s describe it like this: ECS is built upon three fundamental elements: Entities, Components, and Systems. , on their own, lack any inherent functionality or description. Instead, they serve as containers for various Components, which bestow them with specific characteristics for game logic, object rendering, sound effects, and more. Entities , in turn, come in different types and just store data without independent processing capabilities of their own. Components Completing the ECS framework are , which process Components, handle Entity creation and destruction, and manage the addition or removal of Components. Systems For instance, when creating a "Space Shooter" game, the playground will feature multiple objects: the player's spaceship, enemies, asteroids, loot, you name it. All of these objects are considered entities in their own right, devoid of any distinct features. However, by assigning different components to them, we can imbue them with unique attributes. To demonstrate, considering that all these objects possess positions on the game field, we can create a position component that holds the object's coordinates. Furthermore, for the player's spaceship, enemies, and asteroids, we can incorporate health components; the system responsible for handling object collisions will govern the health of these entities. Additionally, we can attach an enemy type component to the enemies, enabling the enemy control system to govern their behavior based on their assigned type. While this explanation provides a simplistic, rudimentary overview, the reality is somewhat more complex. Nonetheless, I trust that the fundamental concept of ECS is clear. With that out of the way, let's delve into the advantages of this approach. The benefits of the Entity Component System One of the main advantages of the Entity Component System (ECS) approach is the architectural design it promotes. (OOP) carries a significant legacy with patterns like inheritance and encapsulation, and even experienced programmers can make architectural mistakes in the heat of development, leading to refactoring or tangled logic in long-term projects. Object-oriented programming In contrast, ECS provides a simple and intuitive architecture. Everything falls naturally into isolated components and systems, making it easier to understand and develop using this approach; even novice developers quickly grasp this approach with minimal errors. ECS follows a composite approach, where isolated components and behavior systems are created instead of complex inheritance hierarchies. These components and systems can be easily added or removed, allowing for flexible changes to entity characteristics and behavior – this approach greatly enhances code reusability. Another key advantage of ECS is performance optimization. In ECS, data is stored in memory in a contiguous and optimized manner, with identical data types placed close to each other. This optimizes data access, reduces cache misses, and improves memory access patterns. Moreover, systems composed of separate data blocks are easier to parallelize across different processes, leading to exceptional performance gains compared to traditional approaches. Exploring the packages of Unity DOTS Unity DOTS encompasses a set of technologies provided by Unity Technologies that implement the ECS concept in Unity. It includes several packages designed to enhance different aspects of game development; let’s cover a few of those now. The core of DOTS is the package, which facilitates the transition from familiar MonoBehaviours and GameObjects to the Entity Component System approach. This package forms the foundation of DOTS-based development. Entities The package introduces a new approach to handling physics in games, achieving remarkable speed through parallelized computations. Unity Physics Additionally, the package allows integration with the modern Havok Physics engine. This engine offers high-performance collision detection and physical simulation, powering popular games such as The Legend of Zelda: Breath of the Wild, Doom Eternal, Death Stranding, Mortal Kombat 11, and more. Havok Physics for Unity The package focuses on rendering in DOTS. It enables efficient gathering of rendering data and works seamlessly with existing render pipelines like the Universal Render Pipeline (URP) or High Definition Render Pipeline (HDRP). Entities Graphics One more thing, Unity has also been actively developing a networking technology called Netcode. It includes packages like Unity Transport for low-level multiplayer game development, Netcode for GameObjects for traditional approaches, and the noteworthy package, which aligns with DOTS principles. These packages are relatively new and will continue to evolve in the future. Unity Netcode for Entities Enhancing performance in Unity DOTS and beyond Several technologies closely related to DOTS can be used within the DOTS framework and beyond. The package provides a convenient way to write code with parallel computations. It revolves around dividing work into small chunks called jobs, which perform computations on their own data. The Job System evenly distributes these jobs across threads for efficient execution. Job System To ensure code safety, the Job System supports the processing of blittable data types. Blittable data types have the same representation in managed and unmanaged memory and require no conversion when passed between managed and unmanaged code. Examples of blittable types include byte, sbyte, short, ushort, int, uint, long, ulong, float, double, IntPtr, and UIntPtr. One-dimensional arrays of blittable primitive types and structures containing exclusively blittable types are also considered blittable. However, types containing a variable array of blittable types are not considered blittable themselves. To address this limitation, Unity has developed the package, which provides a set of unmanaged data structures for use in jobs. These collections are structured and store data in unmanaged memory using Unity mechanisms. It is the developer's responsibility to deallocate these collections using the Disposal() method. Collections Another important package is the , which can be used with the Job System to generate highly optimized code. Although it comes with certain code usage limitations, the Burst compiler provides a significant performance boost. Burst Compiler Measuring performance with Job System and Burst Compile As mentioned, Job System and Burst Compiler are not direct components of DOTS but provide valuable assistance in programming efficient and fast parallel computations. Let's test their capabilities using a practical example: implementing . In this algorithm, a field is divided into cells, each of which can be either alive or dead. During each turn, we check the number of live neighbors for each cell, and their states are updated according to specific rules. Conway's Game of Life algorithm Here’s the implementation of this algorithm using the traditional approach: private void SimulateStep()
{
    Profiler.BeginSample(nameof(SimulateStep));
    
    for (var i = 0; i < width; i++)
    {
        for (var j = 0; j < height; j++)
        {
            var aliveNeighbours = CountAliveNeighbours(i, j);
            var index = i * height + j;

             var isAlive = aliveNeighbours switch
            {
                2 => _cellStates[index],
                3 => true,
                _ => false
            };

             _tempResults[index] = isAlive;
        }
    }
    
    _tempResults.CopyTo(_cellStates);
    Profiler.EndSample();
}

private int CountAliveNeighbours(int x, int y)
{
    var count = 0;
    
    for (var i = x - 1; i <= x + 1; i++)
    {
        if (i < 0 || i >= width) continue;
        
        for (var j = y - 1; j <= y + 1; j++)
        {
            if (j < 0 || j >= height) continue;

            if (_cellStates[i * width + j])
            {
                count++;
            }
        }
    }

    return count;
} I’ve added markers to Profiler to measure the time taken for the calculations. The states of the cells are stored in a one-dimensional array called . We initially write the temporary results to and then copy them back to upon completing the calculations. This approach is necessary because writing the final result directly to would affect subsequent calculations. _cellStates _tempResults _cellStates _cellStates I created a field of 1000x1000 cells and ran the program to measure the performance. Here are the results: As seen from the results, the calculations took 380 ms. Now let's apply the Job System and Burst Compiler to improve the performance. First, we will create the Job responsible for executing the Conway's Game of Life algorithm. public struct SimulationJob : IJobParallelFor
{
    public int Width;
    public int Height;
    [ReadOnly] public NativeArray<bool> CellStates;
    [WriteOnly] public NativeArray<bool> TempResults;

    public void Execute(int index)
    {
        var i = index / Height;
        var j = index % Height;
        var aliveNeighbours = CountAliveNeighbours(i, j);

        var isAlive = aliveNeighbours switch
        {
            2 => CellStates[index],
            3 => true,
            _ => false
        };

        TempResults[index] = isAlive;
    }
    
    private int CountAliveNeighbours(int x, int y)
    {
        var count = 0;
    
        for (var i = x - 1; i <= x + 1; i++)
        {
            if (i < 0 || i >= Width) continue;
        
            for (var j = y - 1; j <= y + 1; j++)
            {
                if (j < 0 || j >= Height) continue;

                if (CellStates[i * Width + j])
                {
                    count++;
                }
            }
        }

        return count;
    }
} I have assigned the attribute to the field, allowing unrestricted access to all values of the array from any thread. However, for the field, which has the attribute, writing can only be done through the index specified in the method. Attempting to write a value to a different index will generate a warning. This ensures data safety when working in a multi-threaded mode. [ReadOnly] CellStates TempResults [WriteOnly] Execute(int index) Now, from the regular code, let's launch our Job: private void SimulateStepWithJob()
{
    Profiler.BeginSample(nameof(SimulateStepWithJob));

    var job = new SimulationJob
    {
        Width = width,
        Height = height,
        CellStates = _cellStates,
        TempResults = _tempResults
    };

    var jobHandler = job.Schedule(width * height, 4);
    jobHandler.Complete();
    job.TempResults.CopyTo(_cellStates);
    Profiler.EndSample();
} After copying all the necessary data, we schedule the execution of the job using the method. It's important to note that this scheduling doesn't immediately execute the calculations: these actions are initiated from the main thread, and the execution happens through workers distributed among different threads. To wait for the job to complete, we use . Only then can we copy the obtained result back to . Schedule() jobHandler.Complete() _cellStates Let's measure the speed: The execution speed has increased almost tenfold, and the execution time is now approximately 42 ms. In the Profiler window, we can see that the workload was distributed among 17 workers. This number is slightly less than the number of processor threads in the test environment, which is an Intel® Core™ i9-10900 with 10 cores and 20 threads. While the results may vary on processors with fewer cores, we can ensure the full utilization of the processor's power. But that's not all – it's time to utilize Burst Compiler, which provides significant code optimization but comes with certain restrictions. To enable Burst Compiler, simply add the attribute to the . [BurstCompile] SimulationJob [BurstCompile]
public struct SimulationJob : IJobParallelFor
{
    ...
} Let's measure again: The results exceed even the most optimistic expectations: speed has increased almost 200 times compared to the initial result. Now, the computation time for 1 million cells is no more than 2 ms. In Profiler, the parts executed by the code compiled with the Burst Compiler are highlighted in green. Conclusion While the use of multithreaded computations may not always be necessary, and the utilization of Burst Compiler may not always be possible, we can observe a common trend in processor development toward multi-core architectures. This means that we should be prepared to harness their full power. ECS, and specifically Unity DOTS, align perfectly with this paradigm. I believe that Unity DOTS deserves attention, at the very least. While it may not be the best solution for every case, ECS can prove its worth in many games. The Unity DOTS framework, with its data-oriented and multithreaded approach, offers tremendous potential for optimizing performance in Unity games. By adopting the Entity Component System architecture and leveraging technologies like the Job System and Burst Compiler, developers can unlock new levels of performance and scalability. As game development continues to evolve and hardware advances, embracing Unity DOTS becomes increasingly valuable. It empowers developers to harness the full potential of modern processors and deliver highly optimized and efficient games. While Unity DOTS may not be the ideal solution for every project, it undoubtedly holds immense promise for those seeking performance-driven development and scalability. Unity DOTS is a powerful framework that can significantly benefit game developers by enhancing performance, enabling parallel computations, and embracing the future of multi-core processing. It’s worth exploring and considering its adoption to fully leverage modern hardware and optimize the performance of Unity games.

Exploring Unity DOTS and ECS: Is it a Game Changer?

ইউনিটি ডটস এবং ইসিএস অন্বেষণ: এটি কি একটি গেম চেঞ্জার?

Erkundung von Unity DOTS und ECS: Ist es ein Game Changer?

Explorando Unity DOTS y ECS: ¿es un cambio de juego?

Exploration de Unity DOTS et ECS : cela change-t-il la donne ?

यूनिटी डॉट्स और ईसीएस की खोज: क्या यह गेम चेंजर है?

Unity DOTS と ECS の探求: それはゲームチェンジャーですか?

Unity DOTS 및 ECS 살펴보기: 게임 체인저인가요?

Explorando Unity DOTS e ECS: é uma virada de jogo?

Unity DOTS ve ECS'yi Keşfetmek: Oyun Değiştirici mi?

Khám phá Unity DOTS và ECS: Nó có phải là yếu tố thay đổi cuộc chơi không?

探索 Unity DOTS 和 ECS：它会改变游戏规则吗？

Hello everyone, my name is Dmitrii Ivashchenko and I'm a software engineer at MY.GAMES. In this article, we'll discuss the differences between garbage collection in Unity and .NET. One of the main advantages of the C# programming language is automatic memory management. It eliminates the need for developers to manually free memory from unused objects and significantly reduces development time. However, this can also lead to a large number of problems related to memory leaks and unexpected application crashes. Aside from general recommendations for avoiding garbage collection issues in C#, it's important to highlight the specifics of memory management implementation in Unity, which result in additional constraints. First, let's examine how memory management works in .NET. Memory management in .NET The (CLR) is the runtime environment for managed code in .NET. Any high-level .NET code written in languages like C#, F#, Visual Basic, and so on, is compiled into Intermediate Language (IL-code), which is then executed in the CLR. In addition to executing IL code, the CLR also provides several other necessary services, such as type safety, security boundaries, and automatic memory management. Common Language Runtime Managed heap When a new CLR process is initialized, it reserves a contiguous region of address space for that process — this space is referred to as the . The managed heap stores a pointer to the address where the next object will be allocated in the heap. Initially, this pointer is set to the base address of the managed heap. All reference types (often value types, too) are placed in the managed heap. managed heap When an application creates the first reference type, memory is allocated for the type at the base address of the managed heap. When creating the next object, the garbage collector allocates memory for it in the address space immediately following the first object. As long as address space is available, the garbage collector continues to allocate space for new objects in this way. Allocating memory from managed heap is faster than allocating unmanaged memory. For example, if you want to allocate memory in C++, you would need to make a system call to the operating system to do this. When using CLR, the memory is already reserved from the OS when the application is launched. Since the runtime allocates memory for an object by adding a value to the pointer, it happens almost as quickly as allocating memory from the stack. Additionally, because new objects that are allocated sequentially are also stored sequentially in the managed heap, an application can access objects very quickly. CLR GC algorithm The garbage collection (GC) algorithm in CLR is based on several considerations: New objects have a shorter life span, while older objects have a longer one. It's faster to compact the memory for a small portion of the managed heap than for the entire managed heap at once. New objects are usually related to each other and are available to the application at approximately the same time. Based on these time-tested assumptions, the CLR garbage collector algorithm is built as follows. There are three generations of objects: Generation 0: all new objects go into this generation. Generation 1: objects from generation 0 that survive one garbage collection are moved into this generation. Generation 2: objects from generation 1 that survive a second garbage collection are moved into this generation. Each generation has its own address space in memory and is processed independently of the others. When an application is launched, the garbage collector places all created objects in the generation 0 space. Once there is no longer enough space for another object, a garbage collection is triggered for generation 0. So, how can we determine the objects no longer in use? To do this, the garbage collector uses the of the application. This list usually includes: list of roots Static fields of classes. Local variables and method parameters. References to objects stored in the thread stack. References to objects stored in processor registers. Objects awaiting finalization. Objects associated with event handlers may also be included in the list of roots. The garbage collector analyzes the list of roots and builds a graph of accessible objects starting from the root objects. Objects that cannot be reached from the root objects are considered dead, and the garbage collector frees up the memory occupied by these objects. After dealing with any dead objects from generation 0, the garbage collector moves the remaining live objects to the address space of generation 1. Once becoming a part of generation 1, objects are less frequently considered by the garbage collector as candidates for removal. Over time, if cleaning up generation 0 does not provide enough space for creating new objects, garbage collection for generation 1 is performed. The graph is constructed again, dead objects are deleted again, and the surviving objects from generation 1 are moved to generation 2. If constant memory leaks are occurring, the garbage collector will consume the available address space of all three generations and decide to request additional space from the operating system. If memory leaks persist, the OS will continue to allocate additional memory to the process up to a certain limit, but when its available memory runs out, it will be forced to stop the process. Some details have intentionally been omitted in this text for ease of understanding, but nonetheless, this allows us to see the complexity and thoughtfulness of memory management organization in .NET. Now, equipped with this knowledge, let's take a look at how this is organized in Unity. Memory management in Unity Since the Unity game engine is written in C++, it obviously uses some amount of memory for its runtime which is not accessible to users (this is called ). It's also important to highlight a special type of memory called , which is used when you use Unity Collections structures like or . All other used memory space is and uses a garbage collector to allocate and free memory. native memory C# unmanaged memory NativeArray<T> NativeList<T> managed memory Due to the absence of CLR, memory management in Unity applications is handled by the scripting runtime (Mono or IL2CPP). However, it should be noted that these environments are not as efficient at memory management as .NET. One of the most frustrating consequences of this is fragmentation. M emory fragmentation Memory fragmentation in Unity is the process where the available memory space is divided into scattered blocks. Fragmentation occurs when an application constantly allocates and deallocates memory, leading to the division of free space in memory into many continuous blocks of different sizes. Memory fragmentation can be of two types: : this occurs when the free space in memory is divided into multiple non-contiguous blocks of different sizes distributed throughout the memory. As a result, there can be enough overall free memory available to accommodate a new object, but there might not be a suitable contiguous block of free space to accommodate it. External fragmentation : this occurs when allocated memory blocks have more space than required to store an object. This leaves unused memory space inside the allocated blocks, which can also lead to inefficient resource utilization. Internal fragmentation Memory fragmentation in Unity is particularly relevant due to the use of a conservative garbage collector that does not support memory compaction. Without compaction, freed memory blocks remain scattered, which can cause performance issues, especially in the long term. The Boehm-Demers-Weiser garbage collector Unity uses the conservative Boehm-Demers-Weiser (BDW) garbage collector, which stops the execution of your program and resumes normal execution only after completing its work. BDW's work algorithm can be described as follows: : the garbage collector pauses program execution for garbage collection. Stop the world : it scans the root pointers, determining all live objects directly accessible from the program code. Root scanning : it follows references from root objects to determine all available objects, creating a graph of accessible objects. Object tracing : it counts the number of references to each object. Reference counting : the garbage collector frees memory occupied by objects that have no references (dead objects). Memory reclamation : after garbage collection is complete, program execution continues. World resumption This is a conservative garbage collector, which means it does not require precise information about the location of all object pointers in memory. Instead, it assumes that any value in memory that can be a pointer to an object is a valid pointer. This allows the BDW garbage collector to work with programming languages that do not provide precise pointer information. Incremental garbage collection Starting with Unity 2019.1, the BDW is used in incremental mode by default. This means that the garbage collector distributes its workload across multiple frames instead of stopping the main CPU thread (stop-the-world garbage collection) to process all objects in the managed heap. Thus, Unity takes shorter breaks while executing your application, instead of having one long interruption, allowing the garbage collector to process objects in the managed heap. Incremental mode does not speed up garbage collection as a whole, but since it distributes the workload across multiple frames, performance spikes related to GC are reduced. Incremental garbage collection can be problematic for your application. In this mode, the garbage collector divides its work, including the marking phase. The marking phase is the scanning of all managed objects by the garbage collector to determine which objects are still in use and which can be cleared. Dividing the marking phase works well when most references between objects do not change between work fragments. However, too many changes can overload the incremental garbage collector and create a situation where the marking phase will never complete. In this case, the garbage collector will switch to performing a full, non-incremental collection. To inform the garbage collector of each reference change, Unity uses write barriers; this adds some overhead when changing references, which affects the performance of managed code. Let's compare: Unity (Boehm-Demers-Weiser) .NET GC Algorithm Conservative garbage collector Generational garbage collector Runtime Environment Mono or IL2CPP .NET Core, .NET Framework, .NET 5+ Root Scanning Less precise root scanning Precise root scanning Object Tracing Yes Yes Reference Counting Yes No Memory Compaction No Yes (except for large objects) Generations No Yes (0, 1, and 2) Speed Slower due to overhead and lack of compactification Faster due to generational approach and precise root scanning Stop-the-world Yes Yes (but with less impact on performance due to incremental garbage collection) Fragmentation Handling Prone to fragmentation (due to lack of object compaction) Reduced fragmentation (due to object compaction) Thus, with no CLR GC in Unity, we get a mechanism prone to heap fragmentation and slow, cumbersome garbage collection in the space of all objects not divided into generations. Let's consider the consequences from this that should be taken into account when developing games in Unity. Avoiding Unity GC limitation pitfalls Due to Unity Incremental GC limitations, the following pain points can be identified: GC calls are more expensive than in .NET (an entire object graph has to be processed, not just its subset). Frequent object creation and deletion leads to memory fragmentation; spaces between objects can only be filled with new objects of equal or smaller size. Frequent changes in object relationships make incremental GC mode difficult to work with (GC cycles take more frames and reduce FPS). Too frequent changes in object relationships (in each frame) result in GC switching to non-incremental mode; instead of spreading GC launches over multiple frames, we get one big world stop until garbage collection is complete. To avoid these pain points, be particularly careful with unnecessary memory allocations in the heap, which can cause garbage collection spikes: avoid passing value type variables instead of reference type variables. This creates a temporary object and potential garbage that is implicitly associated with it, converting value types to object types. A simple example: Boxing: int day = 15;
int month = 10;
int year = 2023;
Debug.Log(string.Format("Date: {0}/{1}/{2}", day, month, year)); It may seem that since , , and are value types and defined inside the function, there will be no allocations or garbage. But if we look into the implementation of , we will see that the arguments are of the type, which means that boxing of value types will occur and they will be placed in the heap: day month year string.Format() object /// Replaces the format items in a specified string with the string
/// representation of three specified objects.
public static string Format(string format, object arg0, object arg1, object arg2); the the C# language, strings are reference types, not value types. Try to minimize the creation and manipulation of strings. Use the class for working with strings during runtime. Strings: StringBuilder although the operator itself does not create garbage, creating a new object does: Coroutines: yield WaitForSeconds private IEnumerator BadExample()
{
  while (true)
  {
    // Creating a new WaitForSeconds object here causes garbage generation.
    yield return new WaitForSeconds(1f);
  }
}

private IEnumerator GoodExample()
{
  // Cache the WaitForSeconds object to avoid garbage generation.
  WaitForSeconds waitForOneSecond = new WaitForSeconds(1f);

  while (true)
  {
    // Reuse the cached WaitForSeconds object.
    yield return waitForOneSecond;
  }
} in general, try to avoid using closures in C# if possible. Minimize the use of anonymous methods and method references in performance-related code, especially if the code runs on every frame. Method references in C# are reference types and they are located on the heap. This means that when you pass a method reference as an argument, temporary memory allocations may occur. This happens regardless of whether an anonymous method is passed or a method is already defined. Moreover, when you turn an anonymous method into a closure, the amount of memory that needs to be passed to the closure method greatly increases. Closures and anonymous methods. both of these tools generate garbage due to hidden boxing. If performance is critical, avoid using LINQ and regular expressions. LINQ and regular expressions: please note that some functions allocate memory on the heap. Keep references to arrays in cache instead of allocating them inside a loop. Also, use functions that don't generate garbage. For example, prefer using instead of comparing strings with (as returning a new string creates garbage). Use non-allocating alternatives to Unity API methods, such as . Unity functions: GameObject.CompareTag GameObject.tag Physics.RaycastNonAlloc If you know that at a certain point in the game the garbage collection process will not affect the gaming experience (for example, on a loading screen), you can initiate garbage collection by calling . However, the best practice to strive for is zero-allocation. This means that you reserve all the memory you need at the start of the game or when loading a specific game scene, and then reuse that memory throughout the entire game cycle. In combination with object pools for reuse and the use of structures instead of classes, these techniques solve most memory management issues in the game. System.GC.Collect

Memory Mastery: Comparing Unity and .NET Garbage Collection

Building an Ethical Text-to-Image AI-Art Site That Pays Royalties to Original Creators

🌈🦄  Building Your Own AI-Generated Art NFT DApp With Bacalhau

🌈🦄 বাকালহাউ দিয়ে আপনার নিজস্ব AI-জেনারেটেড আর্ট NFT DApp তৈরি করুন

🌈🦄 Erstellen Sie mit Bacalhau Ihre eigene KI-generierte Kunst-NFT-DApp

🌈🦄 Creando tu propia DApp Art NFT generada por IA con Bacalhau

🌈🦄 Construisez votre propre DApp NFT Art généré par l'IA avec Bacalhau

🌈🦄 बकलहाऊ के साथ अपनी खुद की एआई-जेनरेटेड आर्ट एनएफटी डीएपी का निर्माण

🌈🦄 Bacalhau を使用して独自の AI 生成アート NFT DApp を構築する

🌈🦄 Bacalhau를 사용하여 나만의 AI 생성 예술 NFT DApp 구축

🌈🦄 Construindo sua própria arte NFT DApp gerada por IA com Bacalhau

🌈🦄 Bacalhau ile Kendi Yapay Zeka ile Üretilmiş Sanat NFT DApp'inizi Oluşturma

🌈🦄 Xây dựng DApp NFT nghệ thuật do AI tạo ra của riêng bạn với Bacalhau

🌈🦄 使用 Bacalhau 构建您自己的 AI 生成艺术 NFT DApp

Gravity Simulation With Unity DOTS 1.0

So I wanted to make an app for our website and well, it turns out it was easier than I thought. So let’s get started : Download & Activate Plugin For Wordpress Blog Step 1 Link: https://wordpress.org/plugins/easily-generate-rest-api-url/ : In the Wordpress dashboard Step 2 Go to settings (hover over it) > (Click on) Generate Rest API Url, scroll to the bottom you will have an api url. You can modify it if you want. : Create a Flutter Project Step 3 If you didn't already, install and setup Flutter from flutter.dev I used vs code but you can use Android studio as well. It will work just the same. : Create functions to fetch posts and post image url Step 4 Create a file named wp-api.dart and then add , and add this function: http package Future< > fetchWpPosts() { response = http. ( ,
      headers: { : }); convertDatatoJson = jsonDecode(response.body); convertDatatoJson;
} List async final await get "https://flutternerd.com/index.php/wp-json/wp/v2/posts" "Accept" "application/json" var return : Create frontend and use this function by importing the file Step 5 ; ; ; { _HomeState createState() => _HomeState();
} { removeAllHtmlTags( htmlText) { exp = ( , multiLine: , caseSensitive: ); htmlText.replaceAll(exp, );
  } Widget build(BuildContext context) { Scaffold(
      appBar: AppBar(
        title: Text( ),
      ),
      body: Container(
        padding: EdgeInsets.only(top: ),
        child: FutureBuilder(
          future: fetchWpPosts(),
          builder: (context, snapshot) { (snapshot.hasData) { ListView.builder(
                  itemCount: snapshot.data.length,
                  itemBuilder: (BuildContext context, index) { wppost = snapshot.data[index]; PostTile(
                        imageApiUrl: wppost[ ][ ][ ]
                            [ ],
                        excerpt: removeAllHtmlTags(wppost[ ][ ]
                            .replaceAll( , )),
                        desc: wppost[ ][ ],
                        title: wppost[ ][ ]
                            .replaceAll( , ));
                  });
            } Center(child: CircularProgressIndicator());
          },
        ),
      ),
    );
  }
} { imageApiUrl, title, desc, excerpt;
  PostTile({ .imageApiUrl, .title, .desc, .excerpt}); _PostTileState createState() => _PostTileState();
} { imageUrl = ; Widget build(BuildContext context) { GestureDetector(
      onTap: () { (imageUrl != ) {
          Navigator.push(
              context,
              MaterialPageRoute(
                  builder: (context) => PostPage(
                        title: widget.title,
                        imageUrl: imageUrl,
                        desc: widget.desc,
                      )));
        }
      },
      child: Container(
        padding: EdgeInsets.symmetric(horizontal: , vertical: ),
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.start,
          children: [
            FutureBuilder(
                future: fetchWpPostImageUrl(widget.imageApiUrl),
                builder: (context, snapshot) { (snapshot.hasData) {
                    imageUrl = snapshot.data[ ][ ]; Image.network(imageUrl);
                  } Center(child: CircularProgressIndicator());
                }),
            SizedBox(height: ),
            Text(
              widget.title,
              style: TextStyle(fontSize: ),
            ),
            SizedBox(height: ),
            Text(widget.excerpt)
          ],
        ),
      ),
    );
  }
} import 'package:flutter/material.dart' import 'package:nativewordpress/views/PostPage.dart' import 'package:nativewordpress/wp-api.dart' class Home extends StatefulWidget @override < > class _HomeState extends State Home String String RegExp RegExp r"<[^>]*>" true true return '' @override return "FlutterNerd" 24 if return int Map return '_links' "wp:featuredmedia" 0 "href" 'excerpt' 'rendered' "&#8217;" "" 'content' 'rendered' 'title' 'rendered' "#038;" "" return class PostTile extends StatefulWidget final String this this this this @override < > class _PostTileState extends State PostTile String "" @override return if "" 16 4 if "guid" "rendered" return return 8 16 5 : We will need to create a separate function to get the image url of each post Step 6 fetchWpPostImageUrl(url) { response = http. (url, headers: { : }); convertDatatoJson = jsonDecode(response.body); convertDatatoJson;
} async final await get "Accept" "application/json" var return : Now let’s create a post page Step 7 We need to add package then flutter_html_view ; ; { imageUrl, title, desc;
  PostPage({ .title, .desc, .imageUrl}); _PostPageState createState() => _PostPageState();
} {
  Widget postContent(htmlContent) { HtmlView(
      data: htmlContent, onLaunchFail: (url) { ( );
      },
      scrollable: ,
    );
  } Widget build(BuildContext context) { Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: SingleChildScrollView(
        child: Padding(
          padding: EdgeInsets.symmetric(horizontal: , vertical: ),
          child: Column(
            crossAxisAlignment: CrossAxisAlignment.start,
            children: [
              widget.imageUrl != ? Image.network(widget.imageUrl)
                  : Container(),
              SizedBox(height: ),
              Text(
                widget.title,
                style: TextStyle(fontSize: ),
              ),
              SizedBox(height: ),
              postContent(
                widget.desc,
              )
            ],
          ),
        ),
      ),
    );
  }
} import 'package:flutter/material.dart' import 'package:flutter_html_view/flutter_html_view.dart' class PostPage extends StatefulWidget final String this this this @override < > class _PostPageState extends State PostPage return // optional, type String // optional, type Function print "launch failed" $url false @override return const 16 16 null 8 18 6 That's it! And that is how we can build an android and ios app for your WordPress blog. If you face any problems feel free to comment down below. Originally published at FlutterNerd.com

7 Steps to Build an Android & IOS App For Your WordPress Blog via Flutter

NATIVECARD

nativecard.io

-- employees

Since n.d.

COMPANY RANKING

NATIVECARD

EVERGREEN INDEX #7509

Representing this company? Click here to claim and customize this page!

Nativecard WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

NATIVECARD

nativecard.io

-- employees

Since n.d.

COMPANY RANKING

NATIVECARD

EVERGREEN INDEX #7509

RELATED COMPANIESRANK

STORIES ABOUT NATIVECARD

Representing this company? Click here to claim and customize this page!

Nativecard WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!