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

think about fjson_object_to_json_string_fn type #24

Open
rgerhards opened this issue Apr 4, 2016 · 2 comments
Open

think about fjson_object_to_json_string_fn type #24

rgerhards opened this issue Apr 4, 2016 · 2 comments
Milestone

Comments

@rgerhards
Copy link
Member

Do we really need level and flags parameters in all functions? Should we replace the function pointers with a switch() statement based on the object type?

@rgerhards rgerhards added this to the 0.99.4 milestone Apr 4, 2016
@davidelang
Copy link

It's a good idea to have flags as future-proofing (there's a good lwn.net article on the topic)

can you point to an example of what you are looking at?

@rgerhards
Copy link
Member Author

Here we have the functions: https://github.com/rsyslog/libfastjson/blob/master/json_object.c#L50

While it is good to have future-proof, in our regard that means we need to write 8 bytes on the stack for each recursive function call (this is one of the hot spots, but less then malloc calls). I am undecided, maybe profiler should suggest the way forward. Alos, this would require some feature-loss. It's something to later look at.

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

No branches or pull requests

2 participants