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

Slow initialization #66

Open
maybeec opened this issue Sep 4, 2017 · 11 comments
Open

Slow initialization #66

maybeec opened this issue Sep 4, 2017 · 11 comments

Comments

@maybeec
Copy link
Contributor

maybeec commented Sep 4, 2017

We observed a very slow initialization of the parser as of google guice.
On initialization of the OpenAPI 3 parser, we are facing a huge delay. As debugging is a little hard without source bundles, I can just guess from what I could see. I finally found google guice to be initialized, which causes seconds of delay. Can you confirm this? Is there any option to skip the usage of google guice or at least make it more performant? Google guice is a heavy weight framework, which most often comes with unnecessary overhead.

@maybeec
Copy link
Contributor Author

maybeec commented Sep 4, 2017

It seems that the performance issue is just present in an osgi environment.

@andylowry
Copy link
Contributor

@maybeec wrote:

It seems that the performance issue is just present in an osgi environment.

That would explain why I hadn't noticed it! I wanted to use DI for the validation code, partly to achieve separation of base parsing from validation of the parsed result. It also makes it possible for users to create custom validators, e.g. to enforce in-house naming policies, etc.

Do you recommend a lighter-weight alternative to guice?

@maybeec
Copy link
Contributor Author

maybeec commented Sep 16, 2017

Dagger 2 might be worth a try. It removes the reflection overhead by utilizing code generation at compile time.
It is even guice compatible as far as I know. So hopefully no migration overhead at all.

@andylowry
Copy link
Contributor

Thanks, @maybeec, I'll take a look.

@KevinMitchell
Copy link

It's also quite slow for me starting up. About four seconds before it gets to the point where the code in my main class starts executing. This is starting the application from the Eclipse IDE on my Mac.

@andylowry
Copy link
Contributor

@KevinMitchell Is your app also osgi-based, as @maybeec reported?

@KevinMitchell
Copy link

KevinMitchell commented Oct 1, 2017 via email

@maybeec
Copy link
Contributor Author

maybeec commented Mar 1, 2018

btw. do you need guice across osgi bundles?
just saw https://github.com/google/guice/wiki/ClassLoading and it is possible to disable the guice custom class loading by the guice_custom_class_loading parameter. Maybe this can make a difference.

I was trying to use Dagger 2, however, you are using some annotations, which does not have any semantic replacement in dagger.

@maybeec
Copy link
Contributor Author

maybeec commented Aug 1, 2018

See the fork of your parser, which has been reworked to remove a log of dependencies, especially the one's with problematic licenses: https://github.com/networknt/openapi-parser
It especially replaces guice and java mail API.

Any chance to make the parser libraries more lightweight?
I also detected, that there are multiple redundant dependencies since the extraction of jsonoverlay. Maybe you want to clean up your dependencies once more.

@tedepstein
Copy link
Contributor

@maybeec , we're hard at work on other things at the moment, but I expect we will circle back and give you a proper response on these questions next week.

@maybeec
Copy link
Contributor Author

maybeec commented Aug 3, 2018

btw we are using the openapi-parser in CobiGen devonfw/tools-cobigen, which is open source now. Unfortunately, we cannot release it as an update site to the public currently as of the license issues with the open api parser. Nontheless, a maven plugin it is already published to maven central.

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

4 participants