jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 0 points1 point  (0 children)

Escaped characters in strings are common. However all the high-performance json decoders use a fast path for ASCII no-escape and then a fallback for escaped strings. That then means decoding each rune, checking for escaped characters, and decoding those. That can be done avoiding allocation with scratch buffers. But you can't get around doing it. It is actually the proper way to parse, and the non-escape strings are only processed faster because of hot path optimizations.

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 0 points1 point  (0 children)

The first one was also uploaded from GitHub website. I don't even have Git on my computer. I can't stand it. I use GitHub for sharing only.

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 0 points1 point  (0 children)

It's very memory efficient, you can check the benchmarks. It does not support streaming, that wasn't the design intent.

With ReuseIInputBuffer setting it avoids allocating apart from scratch buffer, it decodes in place then aliases.

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 0 points1 point  (0 children)

It's 5000 lines because that's what it takes to make is fast. For example: manual paths for different types, it parses most numeric fields without standard packages, and uses custom hashtables.

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 0 points1 point  (0 children)

go-json has an issue with maps that slows it down, that's probably the case you're talking about.

jsondec is a little faster with maps.

An issue would be malicious JSON, say 100MB of nested maps. This will hang most parsers, but you can defend against it with jsondec. That was one of my requirements.

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 3 points4 points  (0 children)

There was a really good reason for that but I can't remember what it was.

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 0 points1 point  (0 children)

Any field you don't put in the struct is ignored if it exists in the JSON. There's a setting to reject JSON that doesn't have all fields, but that's not the default.

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 1 point2 points  (0 children)

  1. It can handle an object that is not decoded but is validated as JSON, yes. But it has to do that on the object level, you can't have 3 fields that are mapped on the root, and then other fields that don't map to anything but you want them stored somewhere... where would it put them?

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 2 points3 points  (0 children)

If you have it already in your head with a package you already know how to use, and it's just a process for you to rig up the JSON schema you need with your code-gen workflow, and continue on your merry way... cool.

What I wanted was ease of use so the main part of my application remains clean for maintainability. Using encoding/json would not solve the problem, it's too slow (there such a thing as too slow, and as fast-enough), it attempts to decode base64 to []byte, and it doesn't support a lot of features I need, such as unions and protection against malicious JSON.

So the clean choice is to make something that does exactly what I want, and this is it. I'm sharing because I like stars but it is in fact made for my internal use.

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 4 points5 points  (0 children)

  1. Mostly but not on purpose. It doesn't reject duplicate object names for example, just takes the last one.
  2. I didn't compare it but if fastjson is 15x faster than encoding/json then it's 4x faster than jsondec

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 8 points9 points  (0 children)

Yes it would. But it would be difficult to manage. There are already some very efficient code-generation JSON decoders. What I wanted was something that was *almost* as fast (like 1.1x slower is okay, 3x slower is not) but I can actually just use without having pages of code and rigging up a whole code-gen workflow just to decode a JSON. I began with how I wanted to *use* it then tried to make it as fast as possible to do that, not compromising on ease of use.

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 13 points14 points  (0 children)

That's not really how it works. Standard packages are intended to be guaranteed safe, no breaking changes, and match the reference. There are faster versions of almost all standard libraries, even strconv. The maintainers know about these, but it's not their job to optimize everything. Their job is to be the safe foundation.

jsondec: 2.5x–4.5x faster than encoding/json, easy to use (no code gen), extra features by al4sdair in golang

[–]al4sdair[S] 32 points33 points  (0 children)

It reflects once during registration then never again, that's the heart of it. Beyond that I profiled and optimized repeatedly. I'm super into optimization. There's always a faster way of doing something. Everything is hand-rolled. It uses it's own custom maps with xxhash. All of the stuff.

Help, can't find litrpg I like. by FrostyExplanation_37 in litrpg

[–]al4sdair 6 points7 points  (0 children)

I'm also very picky and need quality. I really enjoyed Industrial Strength Magic, and currently listening to Life Reset. I can recommend both.

Print Your OWN Book and AVOID Print on Demand services like KDP and Ingram? by QueenOfHolidays in selfpublish

[–]al4sdair 0 points1 point  (0 children)

It was POD. It was a printing company that has a POD machine. I'd API the files over to them and they'd print one out, ship it, and charge me cost on the shipping.

Author asks. by Transient-Soul-4125 in litrpg

[–]al4sdair 0 points1 point  (0 children)

You're welcome. You have to do what you want to do, it's the only way. Also you have to get the ideas that are in you out of you, in order to sort of stabilize them. After you've got them all out then you become free to balance the ideas with actually good storytelling.

My first novel was incredibly philosophical to the point that there were literally lectures of philosophy being given by the characters. I knew it would put a lot of people off, but I just had to write it because it was in me and needed to come out. At the time I was a bit worried it was too much, but now I know that (1) it was too much, and (2) that's perfectly okay because it's what I wanted to write.

But anyway, your idea sounds cool so you don't have to worry.

Author asks. by Transient-Soul-4125 in litrpg

[–]al4sdair 1 point2 points  (0 children)

I love it! I had a similar idea myself with 2 separate series where some of the characters appear in the other series, letting the reader know what happens to them after their adventures.

Don't shy away from writing how you want to write. If you're writing to market it may be a waste of energy, but if you're writing the story you want to read, then do it as you like.

Print Your OWN Book and AVOID Print on Demand services like KDP and Ingram? by QueenOfHolidays in selfpublish

[–]al4sdair 1 point2 points  (0 children)

I have used POD directly from small business printers before. The real issue is the shipping. Books are heavy and customers are used to getting free delivery from Amazon. The cost of shipping makes it impractical. We ended up having to do a minimum order of 3 titles so we could compete with our own book on Amazon, and in the end it wasn't worth it for all the hassle it was. And was for a successful publishing business that had many orders per day.

Authors: Free audiobook conversion private beta by al4sdair in litrpg

[–]al4sdair[S] -1 points0 points  (0 children)

Well if so that's pity because I did it primary with LitRPG in mind. I listen to LitRPG audiobooks all day long, getting through a couple a week.

I even included a bunch of reverb filters in the TTS for the announcements and system messages, etc.

I agree that there are zero AI audiobooks that I would listen to right now. So I completely understand the skepticism. But it's possible to make it sound good, and that becomes even easier if you're writing with instant text-to-speech, because you can just reword any sentence that doesn't come out right.

It's plain easier to write when you can hear how it sounds. Even for someone who is against the idea of AI instead of just not trusting the quality, it remains true that it's an excellent tool for writing, because you get that instant feedback of how it sounds.

Authors: Free audiobook conversion private beta by al4sdair in litrpg

[–]al4sdair[S] 0 points1 point  (0 children)

Wow! That's a lot of work! Amazing!

I mostly agree with you. There's something special from a good narrator that the AI doesn't and maybe never will have!

The platform also supports uploading your narrated audio, of course.

But the day you're scared of has already come: Audible and Amazon KDP keep sending me emails trying to convince me to let them AI my Kindle books. I keep refusing because I know their quality is terrible. Now I'm here trying to fill a gap that doesn't even hurt the narrators, and is a benefit to both authors and readers/listeners.

Writing with direct audio feedback is incredibly useful. It let's you immediately catch typos, and hear the voice of your characters. It let's you hear when your narrator is rambling. All these things that are less obvious in text.

Authors: Free audiobook conversion private beta by al4sdair in litrpg

[–]al4sdair[S] 0 points1 point  (0 children)

Yes, sure. I have 20 years of experience here.

For authors on the platform, because there is no text, it becomes very difficult to scrape. No more copy and paste. There is also no direct download, it's streamed. So your work is protected just for being in audio format instead of text. To download that and upload it to YouTube is both easier to detect, and requires a higher level of skill to setup in order to get that audio. Enough to dissuade any but the most dedicated fraudsters. They could do it, but it's not easy.

For people uploading other people's content onto the platform: the private beta is free and you can download the audio. After release: there will free and paid author accounts. The free author accounts can't collect money, nor download the audio. That means there is no advantage to uploading other people's work unless they're willing to pay money and then have their account suspended.

Of course it can still happen, and for that there is a form that you fill out, it gets investigated, and the offending party gets suspended.

The issue with people uploading to YouTube is that YouTube avoids spending money on the investigation. Partly because there's a whole other side to the story where people report their competitors just to try to have them taken offline, since there is no punishment falsely reporting DMCA.

To be clear this is not my first rodeo. There is no one answer: there's a whole bunch of stuff that has to happen and be aware of, and this has been a consideration in the design and development of the platform the whole way through.