Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move from json encoders/decoders to elm-serialize's codecs #52

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

decioferreira
Copy link

@decioferreira decioferreira commented Dec 11, 2024

Even though the dependencies and modules are not exactly the same, I leave here the comparison between space taken in comparison between elm, JSON encoders/decoders, elm-serialize codecs:

Elm:

% du -sh ~/.elm elm-stuff
4.0M    ~/.elm
6.8M    elm-stuff

JSON encoders/decoders:

% du -sh ~/.guida guida-stuff
8.0M    ~/.guida
 28M    guida-stuff

elm-serialize codecs:

% du -sh ~/.guida guida-stuff
4.9M    ~/.guida
 11M    guida-stuff

Regarding the time it takes to run the test suites, here are the values:

JSON encoders/decoders:

Test Suites: 1 passed, 1 total
Tests:       79 passed, 79 total
Snapshots:   0 total
Time:        55.147 s
Ran all test suites.

elm-serialize codecs:

Test Suites: 1 passed, 1 total
Tests:       79 passed, 79 total
Snapshots:   0 total
Time:        66.516 s
Ran all test suites.

Conflicts:
	src/Builder/Build.elm
	src/Builder/Deps/Registry.elm
	src/Builder/Elm/Details.elm
	src/Builder/Generate.elm
	src/Builder/Reporting/Exit.elm
	src/Compiler/AST/Canonical.elm
	src/Compiler/AST/Optimized.elm
	src/Compiler/AST/Utils/Shader.elm
	src/Compiler/Elm/Compiler/Type/Extract.elm
	src/Compiler/Elm/Docs.elm
	src/Compiler/Elm/Interface.elm
	src/Compiler/Elm/Version.elm
	src/Compiler/Json/Decode.elm
	src/Compiler/Json/Encode.elm
	src/Compiler/Optimize/DecisionTree.elm
	src/Compiler/Reporting/Error/Canonicalize.elm
	src/Compiler/Reporting/Error/Import.elm
	src/Compiler/Reporting/Error/Type.elm
	src/Compiler/Reporting/Render/Type/Localizer.elm
	src/Compiler/Type/Error.elm
	src/Data/Map.elm
	src/Utils/Main.elm
@Warry
Copy link

Warry commented Feb 3, 2025

This is extraordinary great work ! Congrats !

Out of curiosity, is it a goal to be exactly on par with ~/.elm ?

@decioferreira
Copy link
Author

This is extraordinary great work ! Congrats !

@Warry Thank you! That means a lot! 😊 Glad you liked it!

Out of curiosity, is it a goal to be exactly on par with ~/.elm ?

At the moment that is not the intent, but I'm open to consider it if the right use case is presented. The initial implementation was done by using elm/json, which was the easiest option, and also it helped a lot when debugging the initial implementation. Now in this branch, we have 3 available options we could consider picking from: json, bytes and string. And on the package docs we can find the following:

You have three options when encoding data. You can represent the data either as json, bytes, or a string. Here's some advice when choosing:

If performance is important, use encodeToJson and decodeFromJson
If space efficiency is important, use encodeToBytes and decodeFromBytes*
encodeToString and decodeFromString are good for URL safe strings but otherwise one of the other choices is probably better.

Currently, we are focusing on performance. Let me know if this makes sense.

@Warry
Copy link

Warry commented Feb 4, 2025

This is extraordinary great work ! Congrats !

@Warry Thank you! That means a lot! 😊 Glad you liked it!

Out of curiosity, is it a goal to be exactly on par with ~/.elm ?

At the moment that is not the intent, but I'm open to consider it if the right use case is presented.

No particular use case (I can use Elm to compile Elm), you've been very far in the immitation already ! It crossed my mind because I have written elmi and elmo decoder in the past (0.18 era), I know that it's quite annoying to debug. There have been tons of changes in 0.19.1 (UTF-8 in particular), and without the need for it anymore I didn't bother to port it.

The initial implementation was done by using elm/json, which was the easiest option, and also it helped a lot when debugging the initial implementation. Now in this branch, we have 3 available options we could consider picking from: json, bytes and string. And on the package docs we can find the following:

You have three options when encoding data. You can represent the data either as json, bytes, or a string. Here's some advice when choosing:
If performance is important, use encodeToJson and decodeFromJson
If space efficiency is important, use encodeToBytes and decodeFromBytes*
encodeToString and decodeFromString are good for URL safe strings but otherwise one of the other choices is probably better.

Currently, we are focusing on performance. Let me know if this makes sense.

I totally get it ! This is at most "nice to have". If it's not on your radar (well... because it's really peripheral), but you'd be open to pull request, I'd really like to at least figure out what's different, and see if there is a path moving forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants