I'm fairly new to go and I've recently migrated a in-memory cache from node to go for concurrency improvements, but the memory usage difference between the two are huge. I've tried to read up on the map memory model in go but haven't been able to find a reason for the difference. I can't see that I'm doing anything special, so I'm looking for guidance here.

The documents that are stored are around 8 KB in size as a JSON file. In node the memory usage for 50000 documents stored as objects is 1,5 GB, and for go maps it is 10 GB.

To me, this doesn't seem reasonable but I can't find the source of the difference. Could anyone here give their take on this?

In PHP ecosystem there is a tool called Rector. It helps a lot in automated refactoring. It helps a lot in updating from a bad design pattern to another, update code to match a given framework updates, etc.

Maybe we could create a similar tool for client side Javascript to migrate away from jQuery to vanilla Javascript. Websites youmightnotneedjquery.com have a good collections of vanilla JS alternatives to jQuery.

While one could do it manually, on larger code bases, it is extremely tedious.

Maybe such tool exists and I am unaware of it?

At first, I thought about having such transformation as an optimization step in the bundler, but this is unnecessarily redundant and might cause a lot of troubles.

Should I create functions for packages/libraries that allow optional parameters to accept null?

In this example below, I set the 3rd and 4th parameter as null which will act as the default value.

myLibrary::myFunction(1, 7, null, null, true);

Or is this not a good way to go about creating functions for a package and therefore should not accept null as a parameter value.

myLibrary::myFunction(1, 7, false, 4, true);

Should I create functions/methods for packages/libraries that allow optional parameters to accept null?

In this example below, I set the 3rd and 4th parameter as null which will act as the default value.

myLibrary.myFunction(1, 7, null, null, true);

Or is this not a good way to go about creating functions for a package and therefore should not accept null as a parameter value.

myLibrary.myFunction(1, 7, false, 4, true);

From the Creator of HeliumOS, a distro based off AlmaLinux or CentOS Stream on top of the technology of Fedora Atomic Desktops, Bazzite, Fedora coreOS and RHEL Image Mode.

This is a pretty big thing, as extreme stability + stable packages makes the perfect workhorse for an install-and-forget PC.

Together with KDE or other Desktop Environments (CentOS 10 will have Plasma 6 in the external "EPEL" repos) this will be more than a great Windows 10 replacement.

Have all your apps as Flatpak or with a Fedora Distrobox, no problems.

Maybe even an image using packages of the "CentOS Stream Hyperscale SIG" that backports newer Fedora kernel, systemd, mesa and others for improved hardware support, GPU tasks, drivers etc.

It's the same old story, folks.

This was recently posted to discord:

The Original Rogue Legacy Source Code Now Available

Greetings @everyone!

It's been more than 10 years since we released a game that would alter the trajectory of our lives forever. That game, of course, was the original Rogue Legacy. In the span of a single night we went from struggling indie devs to building a solid, stable career making video games; a path that would carry on for more than a decade. Since then we've released two more titles and have reached millions of players worldwide, and it is a journey we hope to continue far into the future.

So, to give back to the community that has gifted us so much, and in the pursuit of sharing knowledge, today we are officially releasing the full source code to Rogue Legacy 1. This may only interest a select few people, but we hope by public sourcing the game that started it all for us, we can keep its spirit alive and help budding developers curious to know what it took for us to get started (and to see what you can get away with :p).

The full source is available at the GitHub link below:

https://github.com/flibitijibibo/RogueLegacy1/

A lifetime of gratitude goes out to Ethan Lee for setting up the public source code repository, and helping us since all the way back to the original Mac and Linux release of Rogue Legacy.

(this is my first post on lemmy, I hope this works like I expect it does. critique and advice are very welcome and appreciated)

fennecs 🔗

Hello, I'm tiger (aka jupiter), and since earlier this year I've been working on a free, libre, and open source Entity-Component System in pure C# that aims to minimize boilerplate and dependencies, works without code generators, and give decent flexibility and performance.

Who is it for?

ECS are an architecture to apply game or other logic to large numbers (ballpark: tens and hundreds of thousands) of objects or actors in an interactive game or simulation, and ECS libraries usually enable expressive composition that go beyond the the intrinsic optimizations of keeping data close together in memory.

fennecs is lightweight and works well with Godot 4.x, The NuGet package is going into its 0.6.0 release soon (about 20 releases so far - see the roadmap)

fennecs is made to operate in just about any sufficiently advanced .NET environment (.NET 8 or later), sadly this precludes using it with Unity for about another two years - but it was created after I spent around five years working with DOTS and coming to the conclusion that it is just too heavy on boilerplate for small teams or solo developers.

There are two simple demos for Godot, a demo for the Stride engine, and when I or one of the other contributors get around to it, demos for raylib_cs, Flax, MonoGame, and others are coming, as well as more demos for Godot.

Possibly ShapeEngine and especially Murder Engine are first in line, though.

What would I like?

Easy - I'd love to hear your thoughts or questions about it if you find the time. It means the world to me to hear other viewpoints or discuss features and contributions with the wider public.

Performance?

Funny you should ask. Everywhere I post, somehow with ECS this appears to be the first question.

Even though top performance isn't the focus (minimum boilerplate is!), thanks to its compact memory layout, fennecs is doing quite all right in Doraku's synthetic C# ECS benchmarks; of which you can find an excerpt on fennecs's github. Performance hardliners can rest assured that another optimization pass comes with the 0.7.x release cycle, after the SIMD interfaces are made available.

Unique traits

fennecs is relational, allowing grouping entities by data-backed relations with other entities (bob owes alice) that are automatically cleaned on entity despawn; by link objects (in physics world P); and soon by arbitrary typed secondary keys (version 0.6.x).

Its Stream Views allow code to access the contiguous storage components are stored in in various ways (including just the raw memory to submit to GPUs or game engines),

Batch operations can modify whole groups of entities or components at once, in a fast and intuitive way.

The SIMD operators currently in development are likely to keep fennecs at the forefront for a wide variety of typical tasks, such as integrating positions and accelerations, matrix transforms, increments, etc.

SIMD ops internally use AVX2, SSE2, and AdvSIMD intrinsics to vectorize their operations where possible, and more complex operations can be composed by sequential ops.

This field is where fennecs' "low boilerplate" design goal doesn't clash with actual high performance and systems programming, and it is great for the optimization stages in game development.

Each release has close to 100% unit test coverage, and because it's pure C#, debugging, inspection and refactoring tools work very well with it.

One last, hidden advantage of being pure C# is that fennecs keeps its data in the .NET domain. Potential performance drawbacks of this are compensated very well by having to marshal function calls and component data back and forth much less frequently than many native-code ECS with C# bindings would.

Games are technically run inside a virtual machine because of differences in how Apple Silicon and x86 systems address memory—Apple's systems use 16 KB memory pages, while x86 systems use 4 KB pages, something that causes issues for Asahi and some other Arm Linux distros on a regular basis and a gap that the VM bridges.

Rosenzweig's post shows off screenshots of Control, Fallout 4, The Witcher 3, Ghostrunner, Cyberpunk 2077, Portal 2, and Hollow Knight, though as she notes, most of these games won't run at anywhere near 60 frames per second yet.

"Correctness comes first. Performance improves next," she writes.

cross-posted from: https://lemmy.ml/post/21365139

Buny

So currently the way I rerun my changes are either by deleting the .next folder or rerunning the npm run dev command because of nextjs' caching (even if I delete the cache on the browser the changes are not reflected). Is there a way to hot reload a nextjs project without using a 3rd party dependency but rather just a set of nextjs configs, just when running a dev build?

Via https://mamot.fr/@fp/113311994869600315

Via https://fosstodon.org/@quentinpradet/113311962538364238

Since the last update, it's not possible to get the [email protected] community page to even load. Can anyone take a look at the problem?