Do you mind me asking, what kind of problems did you run into with Neo4j? Did you encounter performance issues after the DB grew to a certain size, or did you realize that the data wasn't suited to a graph DB and weird query patterns started causing trouble, or was it something else entirely?
I'm considering using a Neo4j self hosted instance for a project, but having only played around with it in low-stakes + small-data toy projects, I'm not really familiar with the footguns and failure modes...
All that aside, plugging holes in a sinking database for six months because you can't come to a descision does not sound like a fun time :D
The first mistake was management not wanting to pay for Neo4J, so we were working in production with the free edition (no backups, only one database, lots of limitations).
The second error was that none of us had production level experience with Neo4J apart from what you just said, tinkering in toy projects at home or very low stakes services, so in the end, the schema that was created was a bit of a mess, you would look at it and say "well, it makes sense..." but in reality we were treating Neo4J as a twisted NoSQL/SQL interpretation.
The third mistake was treating Neo4J as a database meant to handle realtime requests from thousands of users doing filtering and depending on huge responses from external systems (VERY OLD systems, we're talking IBM AS400 old) while in an environment where each response depended on at least 2 or 3 microservices. We had one cypher query to handle almost all use cases, you can imagine what a behemoth that was.
In the end as I said, compound error between lack of experience, not analyzing correctly our needs and a "just go with it attitude" that to this day I'm pretty sure it cost quite a bit to the company. Eventually the backend team managed to move to MySQL (by that time I had moved to Ops) and the difference was abysmal.
Coincidentally, I've been toying with using concludia to make the argument behind a tech design for an upcoming project... when one of our teams is enamored with graph database for it - probably neptune in our case. So far I'm having trouble really nailing down the argument that would justify it.
I'd warn on the side of caution, moving from SQL to Graph is easier than undoing graph nodes, relationships and properties into a coherent SQL schema. Tread carefully :)
I've wanted this for i3, but I guess I wasn't sufficiently motivated :)
Given that sway's homepage describes it as a drop-in replacement for i3, I'll try it out tomorrow.
> - Ports exposed by Docker punch through the firewall
I've been using ufw-docker [1] to force ufw and docker to cooperate. Without it, Docker ports do actually get exposed to to the Internet. As far as I can tell, it does its job correctly.
Is there another problem I am not aware of?
> As an optimization, it is helpful to use a local variable for the reference to the first pointer. Doing so improves the perfomance substantially: C# is not happy when we repeatedly modify a reference. Thus, at the start of the function, you may set byte* mystart = start, use mystart throughout, and then, just before a return, you set start = mystart.
As any method can throw (AccessViolationException in this case), writes to references must be propagated back to the caller immediately. By copying to a local variable, you avoid the requirement that changes are written back to the caller each time. As the sibling comment suggests, this allows the JIT to store the value in a register, not on the stack. Theoretically, the JIT could scan the lifetime of the reference and see if it escapes a try/catch block, then elide the premature writes, but that’s a lot of plumbing work.
In addition, a reference to a pointer is doubly indirect, so you could possibly be increasing latency on reads, depending on how fast the CPU forwards memory accesses.
Lastly, this isn’t idiomatic C#. Sure, vectors are used, but proper C# would be using spans to ensure no buffer overruns, not this “start and end pointer” thing you see in C. I’m also curious how this compares to SearchValues from .NET 8.
There is nothing particularly unidiomatic here - there are multiple ways to approach vectorization in .NET. Such low-level C# flavour is by definition something most developers would never write (even though it has gotten way more convenient and easier to do).
CoreLib heavily leans on "byref arithmetics" over pointer arithmetics, because this allows you to avoid object pinning and may have marginally better codegen at callsites, but it is by no means a requirement.
The code is fine, and it's not dissimilar to how SearchValues internal text search algorithms are implemented. It could be improved by factoring out platform-specific shuffle calls into a helper method and have the core use only portable method calls, but for the sake of demonstrating the point in the article it's absolutely fine.
I would suspect that the JIT treats a reference as a call to somewhere else in memory, which can have considerable overhead in extremely tight loops. By copying a pointer into a local variable, it may hint to the JIT that you want the pointer in a CPU register with faster access.
Or might be something much more subtle. I know C++ can behave this way, but I don't have in depth experience with C# JIT or x86 assembly.
I'm considering using a Neo4j self hosted instance for a project, but having only played around with it in low-stakes + small-data toy projects, I'm not really familiar with the footguns and failure modes...
All that aside, plugging holes in a sinking database for six months because you can't come to a descision does not sound like a fun time :D