I use SimdJsonSharp.Managed.

Exception has occurred: CLR/System.InvalidOperationException
An unhandled exception of type 'System.InvalidOperationException' occurred in SimdJsonSharp.Managed.dll: 'Internal bug'
   at SimdJsonSharp.stage1_find_marks.find_structural_bits(Byte* buf, UInt64 len, ParsedJson pj)
   at SimdJsonSharp.SimdJson.JsonParse(Byte* jsonData, UInt64 length, ParsedJson pj, Boolean reallocIfNeeded)
   at SimdJsonSharp.SimdJson.ParseJson(Byte* jsonData, Int32 length, Boolean reallocIfNeeded)
   at JsonTest.Program.Main(String[] args) in c:\Users\hez20\Desktop\JsonTest\Program.cs:line 14

test code:

using System;
using System.Text;
using SimdJsonSharp;

namespace JsonTest
{
    class Program
    {
        static unsafe void Main(string[] args)
        {
            var p = Encoding.UTF8.GetBytes("{\"test\": 1}");
            fixed (byte* ptr = p)
            {
                var json = SimdJson.ParseJson(ptr, p.Length);
            }
            return;
        }
    }
}

Version 0.4 of simdjson is now available

Highlights

• Test coverage has been greatly improved and we have resolved many static-analysis warnings on different systems.

New features:

• We added a fast (8GB/s) minifier that works directly on JSON strings.
• We added fast (10GB/s) UTF-8 validator that works directly on strings (any strings, including non-JSON).
• The array and object elements have a constant-time size() method.

Performance:

• Performance improvements to the API (type(), get<>()).
• The parse_many function (ndjson) has been entirely reworked. It now uses a single secondary thread instead of several new threads.
• We have introduced a faster UTF-8 validation algorithm (lookup3) for all kernels (ARM, x64 SSE, x64 AVX).

System support:

• C++11 support for older compilers and systems.
• FreeBSD support (and tests).
• We support the clang front-end compiler (clangcl) under Visual Studio.
• It is now possible to target ARM platforms under Visual Studio.
• The simdjson library will never abort or print to standard output/error.

Version 0.3 of simdjson is now available

Highlights

• Multi-Document Parsing: Read a bundle of JSON documents (ndjson) 2-4x faster than doing it individually. API docs / Design Details
• Simplified API: The API has been completely revamped for ease of use, including a new JSON navigation API and fluent support for error code and exception styles of error handling with a single API. Docs
• Exact Float Parsing: Now simdjson parses floats flawlessly without any performance loss (simdjson/simdjson#558).
  Blog Post
• Even Faster: The fastest parser got faster! With a shiny new UTF-8 validator
  and meticulously refactored SIMD core, simdjson 0.3 is 15% faster than before, running at 2.5 GB/s (where 0.2 ran at 2.2 GB/s).

Minor Highlights

• Fallback implementation: simdjson now has a non-SIMD fallback implementation, and can run even on very old 64-bit machines.
• Automatic allocation: as part of API simplification, the parser no longer has to be preallocated-it will adjust automatically when it encounters larger files.
• Runtime selection API: We've exposed simdjson's runtime CPU detection and implementation selection as an API, so you can tell what implementation we detected and test with other implementations.
• Error handling your way: Whether you use exceptions or check error codes, simdjson lets you handle errors in your style. APIs that can fail return simdjson_result, letting you check the error code before using the result. But if you are more comfortable with exceptions, skip the error code and cast straight to T, and exceptions will be thrown automatically if an error happens. Use the same API either way!
• Error chaining: We also worked to keep non-exception error-handling short and sweet. Instead of having to check the error code after every single operation, now you can chain JSON navigation calls like looking up an object field or array element, or casting to a string, so that you only have to check the error code once at the very end.

Hi,
I wanted to try out this awesome piece of code, but not 100% why nuget installation fails with following message:

Detected package downgrade: Microsoft.NETCore.Platforms from 3.0.0-preview3.19115.9 to 3.0.0-preview.19073.11. Reference the package directly from the project to select a different version. 
 OriginClient -> SimdJsonSharp 1.0.3 -> Microsoft.NETCore.Platforms (>= 3.0.0-preview3.19115.9) 
 OriginClient -> Microsoft.NETCore.Platforms (>= 3.0.0-preview.19073.11)
Package restore failed. Rolling back package changes for 'OriginClient'.

I've got .NET Core 3.0.0-preview2 installed on my machine, it's not yet compatible with it?
Thanks!

The library simdjson has a new major release (0.2.0). Major changes:

• Support for 64-bit ARM processors, can run under iOS (iPhone).
• Runtime dispatching on x64 processors (switches to SSE on older x64 processors, uses AVX2 when available). Supports processors as far back as the Intel Westmere.
• More accurate number parsing.
• Fixes most warnings under Visual Studio.
• Several small bugs have been fixed.
• Better performance in some cases.
• Introduces a JSON Pointer interface https://tools.ietf.org/html/rfc6901
• Better and more specific error messages (with optional textual descriptions).
• valgrind clean.
• Unified code style (LLVM).

Shout when this is published to nuget so we can play :)

It fixes a few potential buffer overruns for adversarial inputs. It should be safer.

Now that .NET Standard and .NET Core 3.0 is out, do you have any plans to further optimize the library by using ArrayPool and Span<T>?

We have a new version which has precomputed string lengths, and supporting strings with null characters in them.

Just a thought...
I could imagine an arena allocator doing quite well in this kind of use case.
@mgravell introduced a C# implementation here:
https://github.com/mgravell/Pipelines.Sockets.Unofficial/blob/master/docs/arenas.md

Nice work. As you know RyuJIT can test for ISA level support at codegen time. Do you plan to attempt to offer a SIMD codepath for CPU without AVX2? They are still fairly common I guess.

@tannergooding

Using SimdJsonSharp.Bindings for a project using .NET 4.0 framework on Windows 11.

Facing the following build error

CSC : error CS8002: Referenced assembly 'SimdJsonSharp.Bindings, Version=1.7.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.

Based on my investigation, this usually happens when the strongly named assembly is referencing an assembly(-ies) that does not have a strong name. A solution here would be to sign the assembly package and all the referenced assemblies.

This will pose a security risk for any future users. Can you please look into this?
If you need any further details to reproduce the issue, please let me know. I'd be happy to contribute and help fix it as well.

Using SimdJsonSharp.Managed nuget with a .Net5 console application in VS19 on Windows 10 with AVX2 support i am able to reproduce an access violation with some Json files.

After a first investigation it looks like the expected padding (SIMDJSON_PADDING) doesn't work. My memory window is showing that there were only very few additional bytes added at the end of my json byte array (probably by debug mode).

The value of 'ptr' was pointing to the selected character shown in the memory window / see 'Autos' window bottom left.

The shown decompiled line seems to correspond to:

If it helps i can share the source code and json .

Workaround: Adding the padding of 32 bytes and the end of the input byte array solved this issue.

I have tried to add SimdJsonSharp to my serializer perfomrance test suite. See https://github.com/Alois-xx/SerializerTests

When you compile it and let it run on .NET Core Preview 7

D:\Source\git\SerializerTests\bin\Debug\netcoreapp3.0>SerializerTests.exe -test combined -serializer Utf8JsonSerializer,SimdJsonSharpSerializer,SimdJsonSharpSerializerN

Serializer      Objects "Time to serialize in s"        "Time to deserialize in s"      "Size in bytes" FileVersion     Framework       ProjectHome     DataFormat      FormatDetails   Supports Versioning
SimdJsonSharpSerializer 1000000 0.1310  0.116   35777803        1.5.0.0 .NET Core 3.0.0-preview7-27912-14       https://github.com/EgorBo/SimdJsonSharp based on https://github.com/lemire/simdjson     Text    Json    No
SimdJsonSharpSerializerN        1000000 0.1117  3.139   35777803        1.7.0.0 .NET Core 3.0.0-preview7-27912-14       https://github.com/EgorBo/SimdJsonSharp based on https://github.com/lemire/simdjson     Text    Json    No
Utf8JsonSerializer      1000000 0.1135  0.330   35777803        1.3.7   .NET Core 3.0.0-preview7-27912-14       https://github.com/neuecc/Utf8Json      Text    Json    Yes

I find the native version needs 3s vs 0.1s for the managed version.

When lookint at the data in PerfView I find most time is spent in paserJson. Why this is so costly I cannot tell but it looks wasteful. Can you take a look why this is so much slower? Am I using the library the wrong way?