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

Editing becomes very slow as time goes #2

Closed
ddenisenko opened this Issue Nov 3, 2015 · 43 comments

Comments

@ddenisenko
Contributor

ddenisenko commented Nov 3, 2015

It happened recently. Either completion or validation slows things down.

As a reproduction, try typing the following text:

#%RAML 1.0
title: Pet shop
version: 1
baseUri: /shop
types:
  Pet:
    properties:
      name: string
      kind: string
      price: number
    example:
      name: "Snoopy"
      kind: "Mammal"
      price: 100

resourceTypes:

  Collection:
    get:
      responses:
        200:
          body:
            application/json:
              type: <<item>>[]
    post:
      body:
        application/json:
          type: <<item>>

  Member:
    put:
      body:
        application/json:
          type: <<item>>
    delete:
      responses:
        204:

traits:
  FilterableByPrice:
    queryParameters:
      priceLessThen?:
        type: number
      priceMoreThen?:
        type: number

/pets:
  type: { Collection: {item: Pet} }
  get:
    is: FilterableByPrice
    queryParameters:
      petKind:
       enum: [bird, mammal]
  /{id}:
    type: { Member: {item : Pet} }
@ddenisenko

This comment has been minimized.

Show comment
Hide comment
@ddenisenko

ddenisenko Nov 3, 2015

Contributor

Relevant comments:

Pavel: Sorry . It did not looks reproducible for me. I will try to ask for reproduction sequence

Denis: More recommendations. Clone this file 20 times, and try editing the samples one by one. Restarting Atom makes it fast again.

Pavel: okey, so this is a slow down after some time of editing.

Pavel: What we need to do now is to reproduce it again.

Contributor

ddenisenko commented Nov 3, 2015

Relevant comments:

Pavel: Sorry . It did not looks reproducible for me. I will try to ask for reproduction sequence

Denis: More recommendations. Clone this file 20 times, and try editing the samples one by one. Restarting Atom makes it fast again.

Pavel: okey, so this is a slow down after some time of editing.

Pavel: What we need to do now is to reproduce it again.

@menduz

This comment has been minimized.

Show comment
Hide comment
@menduz

menduz Jan 5, 2016

Same here, with a small file using 0.8 spec. Takes about 1sec since I hit a key until its shown on the screen. Maybe the whole file is re-parsed on every change.. In that case a debounce may be good

menduz commented Jan 5, 2016

Same here, with a small file using 0.8 spec. Takes about 1sec since I hit a key until its shown on the screen. Maybe the whole file is re-parsed on every change.. In that case a debounce may be good

@redndahead

This comment has been minimized.

Show comment
Hide comment
@redndahead

redndahead Jan 13, 2016

I'll add my voice to this. It gets pretty slow after a while. I'm not sure I can put a finger on the exact cause, but I definitely notice it within the autocomplete.

redndahead commented Jan 13, 2016

I'll add my voice to this. It gets pretty slow after a while. I'm not sure I can put a finger on the exact cause, but I definitely notice it within the autocomplete.

@sichvoge

This comment has been minimized.

Show comment
Hide comment
@sichvoge

sichvoge Jan 13, 2016

Contributor

We are trying to find the root cause, but so far without luck as it appears to be very infrequent and there is no - this is an example to reproduce - case unfortunately.

Contributor

sichvoge commented Jan 13, 2016

We are trying to find the root cause, but so far without luck as it appears to be very infrequent and there is no - this is an example to reproduce - case unfortunately.

@davidpelaez

This comment has been minimized.

Show comment
Hide comment
@davidpelaez

davidpelaez Jan 20, 2016

I wanted to confirm that this is real. I have removed the package because at some points Atom stops receiving keystrokes and it can't be used. Maybe there's an N+1 loop somewhere or maybe a part of the calculation on the syntax tree can be cached? I'm happy to contribute information like logs or something that could be useful to debug but I don't know what exactly. If you point me in the right direction I can send the data you request.

davidpelaez commented Jan 20, 2016

I wanted to confirm that this is real. I have removed the package because at some points Atom stops receiving keystrokes and it can't be used. Maybe there's an N+1 loop somewhere or maybe a part of the calculation on the syntax tree can be cached? I'm happy to contribute information like logs or something that could be useful to debug but I don't know what exactly. If you point me in the right direction I can send the data you request.

@ddenisenko

This comment has been minimized.

Show comment
Hide comment
@ddenisenko

ddenisenko Jan 20, 2016

Contributor

@davidpelaez The most hard part here is the issue reproduction. Can you zip and share the RAML project you are encountering this issue at, and described a bit of what you were generally doing when you noticed the issue?

Note: restarting Atom should help.

Contributor

ddenisenko commented Jan 20, 2016

@davidpelaez The most hard part here is the issue reproduction. Can you zip and share the RAML project you are encountering this issue at, and described a bit of what you were generally doing when you noticed the issue?

Note: restarting Atom should help.

@davidpelaez

This comment has been minimized.

Show comment
Hide comment
@davidpelaez

davidpelaez Jan 21, 2016

I was working on this https://github.com/davidpelaez/erp-api-rjc Basically writing docs, and creating resources and types where autocompletion would appear. Autocompletion seems to play a big deal but this was happening everywhere I typed and I started noticing it progressively emerge as the document got longer.

davidpelaez commented Jan 21, 2016

I was working on this https://github.com/davidpelaez/erp-api-rjc Basically writing docs, and creating resources and types where autocompletion would appear. Autocompletion seems to play a big deal but this was happening everywhere I typed and I started noticing it progressively emerge as the document got longer.

@davidpelaez

This comment has been minimized.

Show comment
Hide comment
@davidpelaez

davidpelaez Jan 21, 2016

Restarting helps but for a very limited time. Let me know if there's anything else I can add to help.

davidpelaez commented Jan 21, 2016

Restarting helps but for a very limited time. Let me know if there's anything else I can add to help.

@davidpelaez

This comment has been minimized.

Show comment
Hide comment
@davidpelaez

davidpelaez Jan 21, 2016

Also, it was so painfully slow that I just placed a lot of stuff in comments because I needed to send the spec to a customer and I felt bad not having datatypes in 0.8 :P

davidpelaez commented Jan 21, 2016

Also, it was so painfully slow that I just placed a lot of stuff in comments because I needed to send the spec to a customer and I felt bad not having datatypes in 0.8 :P

@ddenisenko

This comment has been minimized.

Show comment
Hide comment
@ddenisenko

ddenisenko Jan 26, 2016

Contributor

@davidpelaez thank you, we reproduced the issue.

It is hard to fix as it is related to atom's internal code storing links for detached dom nodes, for now you can just close RAML Editor tools (two panels in the right), this should stop leaks to happen.

Contributor

ddenisenko commented Jan 26, 2016

@davidpelaez thank you, we reproduced the issue.

It is hard to fix as it is related to atom's internal code storing links for detached dom nodes, for now you can just close RAML Editor tools (two panels in the right), this should stop leaks to happen.

@davidpelaez

This comment has been minimized.

Show comment
Hide comment
@davidpelaez

davidpelaez Jan 26, 2016

It does indeed makes it easier, but I since autocomplete still works in the background the problem persists to some extent. Even with the panels closed it can stop being usable after some minutes of typing.

davidpelaez commented Jan 26, 2016

It does indeed makes it easier, but I since autocomplete still works in the background the problem persists to some extent. Even with the panels closed it can stop being usable after some minutes of typing.

@ddenisenko

This comment has been minimized.

Show comment
Hide comment
@ddenisenko

ddenisenko Jan 26, 2016

Contributor

@davidpelaez Please confirm if you can reproduce the same issue with:

  1. Atom restarted
  2. Right after Atom restart Editor Tools are closed and never opened again.

For now I see the memory leak coming from outline details due to detached DOM nodes still live as being referenced from atom's document pollers.

Contributor

ddenisenko commented Jan 26, 2016

@davidpelaez Please confirm if you can reproduce the same issue with:

  1. Atom restarted
  2. Right after Atom restart Editor Tools are closed and never opened again.

For now I see the memory leak coming from outline details due to detached DOM nodes still live as being referenced from atom's document pollers.

@ProLoser

This comment has been minimized.

Show comment
Hide comment
@ProLoser

ProLoser Jan 27, 2016

I am curious if this can also be caused by large json files (for examples and schemas) which are then validated against each other, creating recursive parsing and validation. If you make corrections to file paths this also seems to move slowly.

ProLoser commented Jan 27, 2016

I am curious if this can also be caused by large json files (for examples and schemas) which are then validated against each other, creating recursive parsing and validation. If you make corrections to file paths this also seems to move slowly.

@rocketraman

This comment has been minimized.

Show comment
Hide comment
@rocketraman

rocketraman Apr 24, 2016

Please confirm if you can reproduce the same issue with:

  1. Atom restarted
  2. Right after Atom restart Editor Tools are closed and never opened again.

I can definitely reproduce the issue with the above two constraints. Let me know what additional information I can provide.

rocketraman commented Apr 24, 2016

Please confirm if you can reproduce the same issue with:

  1. Atom restarted
  2. Right after Atom restart Editor Tools are closed and never opened again.

I can definitely reproduce the issue with the above two constraints. Let me know what additional information I can provide.

@ddenisenko

This comment has been minimized.

Show comment
Hide comment
@ddenisenko

ddenisenko Apr 27, 2016

Contributor

@rocketraman Please also make sure you do not have API Console opened. So, Atom restart, Editor Tools closed, Console closed, and never opened.

Also, do you see the performance degrading after some time or it is slow from the start?

Contributor

ddenisenko commented Apr 27, 2016

@rocketraman Please also make sure you do not have API Console opened. So, Atom restart, Editor Tools closed, Console closed, and never opened.

Also, do you see the performance degrading after some time or it is slow from the start?

@redndahead

This comment has been minimized.

Show comment
Hide comment
@redndahead

redndahead Apr 27, 2016

@ddenisenko How do you start it closed. No matter if I close it before exiting atom it always starts with it being opened.

redndahead commented Apr 27, 2016

@ddenisenko How do you start it closed. No matter if I close it before exiting atom it always starts with it being opened.

@sichvoge

This comment has been minimized.

Show comment
Hide comment
@sichvoge

sichvoge Apr 27, 2016

Contributor

Really, for me the console is never open. I just close the tab where the console is and thats it.

Contributor

sichvoge commented Apr 27, 2016

Really, for me the console is never open. I just close the tab where the console is and thats it.

@redndahead

This comment has been minimized.

Show comment
Hide comment
@redndahead

redndahead Apr 27, 2016

Right but what happens when you quit atom and start it again? For me the console and details tabs open again.

redndahead commented Apr 27, 2016

Right but what happens when you quit atom and start it again? For me the console and details tabs open again.

@rocketraman

This comment has been minimized.

Show comment
Hide comment
@rocketraman

rocketraman Apr 27, 2016

@rocketraman Please also make sure you do not have API Console opened. So, Atom restart, Editor Tools closed, Console closed, and never opened.

Yes, I restart Atom and immediately close the two Editor Tools ("Outline" and "Details") on the right (yes, they reopen on every restart but I don't think there is any way to prevent that -- I just close them right away). The console is never open. The "Issues" list at the bottom is still open but I don't see a way to close that.

Also, do you see the performance degrading after some time or it is slow from the start?

The performance is pretty slow right from the start, but I'm pretty sure it degrades even more over time.

rocketraman commented Apr 27, 2016

@rocketraman Please also make sure you do not have API Console opened. So, Atom restart, Editor Tools closed, Console closed, and never opened.

Yes, I restart Atom and immediately close the two Editor Tools ("Outline" and "Details") on the right (yes, they reopen on every restart but I don't think there is any way to prevent that -- I just close them right away). The console is never open. The "Issues" list at the bottom is still open but I don't see a way to close that.

Also, do you see the performance degrading after some time or it is slow from the start?

The performance is pretty slow right from the start, but I'm pretty sure it degrades even more over time.

@rocketraman

This comment has been minimized.

Show comment
Hide comment
@rocketraman

rocketraman Apr 27, 2016

BTW, this might be a useful tool to get a little bit more useful data about this issue: https://pavelfatin.com/typometer/

rocketraman commented Apr 27, 2016

BTW, this might be a useful tool to get a little bit more useful data about this issue: https://pavelfatin.com/typometer/

@sichvoge

This comment has been minimized.

Show comment
Hide comment
@sichvoge

sichvoge Apr 30, 2016

Contributor

It also seems that it is not only the API Workbench, but also Atom itself that has problems with performance (see here). We definitely do not stop to analyze the problem for the workbench package, but its not that easy if the problem does not only is about this package. :(

Contributor

sichvoge commented Apr 30, 2016

It also seems that it is not only the API Workbench, but also Atom itself that has problems with performance (see here). We definitely do not stop to analyze the problem for the workbench package, but its not that easy if the problem does not only is about this package. :(

@sichvoge

This comment has been minimized.

Show comment
Hide comment
@sichvoge

sichvoge May 2, 2016

Contributor

OK, I've also done some testing. For me editing else becomes slow after some time especially when the Editor Tools are open (Outline and Details). Closing them helps to get better performance. @ddenisenko do you think we can switch to not show them immediately when you open a RAML file?

Contributor

sichvoge commented May 2, 2016

OK, I've also done some testing. For me editing else becomes slow after some time especially when the Editor Tools are open (Outline and Details). Closing them helps to get better performance. @ddenisenko do you think we can switch to not show them immediately when you open a RAML file?

@usarid

This comment has been minimized.

Show comment
Hide comment
@usarid

usarid May 2, 2016

Contributor

Why would we do that, when there could be a problem in our code? See eg https://discuss.atom.io/t/why-is-atom-so-slow/11376/133 . There's a lot of value in these modules, and people might not discover them otherwise. Should we just try harder to understand and maybe work around the problem that's causing slowness in our specific case?

_____________________________

From: Christian Vogel notifications@github.com
Sent: Monday, May 2, 2016 5:45 AM
Subject: Re: [mulesoft/api-workbench] Editing becomes very slow as time goes (#2)
To: mulesoft/api-workbench api-workbench@noreply.github.com

OK, I've also done some testing. For me editing else becomes slow after some time especially when the Editor Tools are open (Outline and Details). Closing the helps to get better performance. @ddenisenko do you think we can switch to not show them immediately when you open a RAML file?


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

Contributor

usarid commented May 2, 2016

Why would we do that, when there could be a problem in our code? See eg https://discuss.atom.io/t/why-is-atom-so-slow/11376/133 . There's a lot of value in these modules, and people might not discover them otherwise. Should we just try harder to understand and maybe work around the problem that's causing slowness in our specific case?

_____________________________

From: Christian Vogel notifications@github.com
Sent: Monday, May 2, 2016 5:45 AM
Subject: Re: [mulesoft/api-workbench] Editing becomes very slow as time goes (#2)
To: mulesoft/api-workbench api-workbench@noreply.github.com

OK, I've also done some testing. For me editing else becomes slow after some time especially when the Editor Tools are open (Outline and Details). Closing the helps to get better performance. @ddenisenko do you think we can switch to not show them immediately when you open a RAML file?


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

@redndahead

This comment has been minimized.

Show comment
Hide comment
@redndahead

redndahead May 3, 2016

In my opinion if I set the windows to close it should stay closed until I decide to open it again. You should have it opened when atom is first installed, but after that it should be up to me if I ever want to see them again.

And you should fix the actual issue. ;)

redndahead commented May 3, 2016

In my opinion if I set the windows to close it should stay closed until I decide to open it again. You should have it opened when atom is first installed, but after that it should be up to me if I ever want to see them again.

And you should fix the actual issue. ;)

@usarid

This comment has been minimized.

Show comment
Hide comment
@usarid

usarid May 4, 2016

Contributor

Yes, and yes.

Contributor

usarid commented May 4, 2016

Yes, and yes.

@sichvoge

This comment has been minimized.

Show comment
Hide comment
@sichvoge

sichvoge May 13, 2016

Contributor

It seems that the details/outline panel might be one problem. We did some more investigation and it seems we have three different tasks to do to see if that will increase the performance.

  1. there are leaks inside the parser and workbench that needs to be fixed
  2. optimize the JS parser
  3. validation does currently not fully leverage workers in the api workbench

Our current plan is to work us through 1 --> 3, having 1 done with our Monday release.

Contributor

sichvoge commented May 13, 2016

It seems that the details/outline panel might be one problem. We did some more investigation and it seems we have three different tasks to do to see if that will increase the performance.

  1. there are leaks inside the parser and workbench that needs to be fixed
  2. optimize the JS parser
  3. validation does currently not fully leverage workers in the api workbench

Our current plan is to work us through 1 --> 3, having 1 done with our Monday release.

@ddenisenko

This comment has been minimized.

Show comment
Hide comment
@ddenisenko

ddenisenko Dec 1, 2016

Contributor

There are the following aspects, which can be improved:

  1. Memory handling
  2. Parsing speed
  3. Moving parsing activities to background.

Memory handling basically means we need to fix recently discovered memory leaks.
Memory leaks are found in two areas: typesystem and atom edit components.
The first kind of leaks was fixed and will be released soon. This should reduce memory consumption speed greatly and make it quite easier for the users.
The second kind of leaks is under the fixing process right now. I'll provide the updates.

Parsing speed is more related to https://github.com/raml-org/raml-js-parser-2 repository, but, generally, there are two kinds of efforts there: to improve parsing speed in general, and to reuse the results of parsing for the dependent files: fragments, libraries, schemas. The idea is to make improvements for the case when user is continuously modifying a single file so that we try to avoid reparsing other files and reusing previous parsing results instead. This is also something under development right now.

The last efforts is to make all parsing-related activities to run in background so the speed of typing is unaffected even if those activities consume noticeable amount of CPU. We will start implementing this in about 2 weeks.

Contributor

ddenisenko commented Dec 1, 2016

There are the following aspects, which can be improved:

  1. Memory handling
  2. Parsing speed
  3. Moving parsing activities to background.

Memory handling basically means we need to fix recently discovered memory leaks.
Memory leaks are found in two areas: typesystem and atom edit components.
The first kind of leaks was fixed and will be released soon. This should reduce memory consumption speed greatly and make it quite easier for the users.
The second kind of leaks is under the fixing process right now. I'll provide the updates.

Parsing speed is more related to https://github.com/raml-org/raml-js-parser-2 repository, but, generally, there are two kinds of efforts there: to improve parsing speed in general, and to reuse the results of parsing for the dependent files: fragments, libraries, schemas. The idea is to make improvements for the case when user is continuously modifying a single file so that we try to avoid reparsing other files and reusing previous parsing results instead. This is also something under development right now.

The last efforts is to make all parsing-related activities to run in background so the speed of typing is unaffected even if those activities consume noticeable amount of CPU. We will start implementing this in about 2 weeks.

dreamflyer added a commit to raml-org/raml-typesystem that referenced this issue Dec 6, 2016

@dreamflyer

This comment has been minimized.

Show comment
Hide comment
@dreamflyer

dreamflyer Dec 9, 2016

Contributor

will be published in v0.8.41

Contributor

dreamflyer commented Dec 9, 2016

will be published in v0.8.41

@dreamflyer dreamflyer closed this Dec 9, 2016

@sichvoge sichvoge removed the ready label Dec 9, 2016

@sonicdivx

This comment has been minimized.

Show comment
Hide comment
@sonicdivx

sonicdivx Feb 8, 2017

I am seeing this issue, and have the latest version available via "check for updates" (0.8.43) within Atom.

sonicdivx commented Feb 8, 2017

I am seeing this issue, and have the latest version available via "check for updates" (0.8.43) within Atom.

@ddenisenko

This comment has been minimized.

Show comment
Hide comment
@ddenisenko

ddenisenko Feb 11, 2017

Contributor

@sonicdivx do you have it "just being slow", or its slows down over time? It's easy to check: if restarting Atom makes it fast again for some time, then it's probably the memory leak issue.

Contributor

ddenisenko commented Feb 11, 2017

@sonicdivx do you have it "just being slow", or its slows down over time? It's easy to check: if restarting Atom makes it fast again for some time, then it's probably the memory leak issue.

@sonicdivx

This comment has been minimized.

Show comment
Hide comment
@sonicdivx

sonicdivx Feb 11, 2017

Yes a restart she's improve things and yes eventually slows down. Also I have one include and 10 libraries. Though this did this just temporarily so could minimize scrolling. If there was a way to turn off validation could narrow down if that is where the leak is occurring

sonicdivx commented Feb 11, 2017

Yes a restart she's improve things and yes eventually slows down. Also I have one include and 10 libraries. Though this did this just temporarily so could minimize scrolling. If there was a way to turn off validation could narrow down if that is where the leak is occurring

@ddenisenko

This comment has been minimized.

Show comment
Hide comment
@ddenisenko

ddenisenko Feb 11, 2017

Contributor

No, you can't turn off validation, because parsing is something every other component rely upon.

What you can do, for now, is to close RAML editing tools (two panes on the right) and see if it helps. Let us know the results.

We will try reproducing locally. It would be helpful if you can provide RAML (including libraries etc) for reproduction.

Contributor

ddenisenko commented Feb 11, 2017

No, you can't turn off validation, because parsing is something every other component rely upon.

What you can do, for now, is to close RAML editing tools (two panes on the right) and see if it helps. Let us know the results.

We will try reproducing locally. It would be helpful if you can provide RAML (including libraries etc) for reproduction.

@ddenisenko

This comment has been minimized.

Show comment
Hide comment
@ddenisenko

ddenisenko Feb 11, 2017

Contributor

@dreamflyer please try reproducing.

Contributor

ddenisenko commented Feb 11, 2017

@dreamflyer please try reproducing.

@ddenisenko ddenisenko reopened this Feb 11, 2017

@sonicdivx

This comment has been minimized.

Show comment
Hide comment
@sonicdivx

sonicdivx Feb 13, 2017

I may not be able to provide RAML as the API is not publicly available, yet. I will try closing the other panes and see what happens. I am under a deadline, but if I can anonymize the api I will and send it.

I can tell you that the number of DataTypes is in the hundreds. Endpoints is also very in the hundreds. I did pull the Datatypes into some 20 libraries (not necessarily permanent, just to reduce scrolling). The Initial version of the API was pulled from .Net using the RAML .Net Tools to autogenerate.

the reason not using as is, There are some aspects of the definition that are incomplete or DataTypes poorly named (though as I am learning things, I have poorly named a few things - a refactor in my future ;) )

sonicdivx commented Feb 13, 2017

I may not be able to provide RAML as the API is not publicly available, yet. I will try closing the other panes and see what happens. I am under a deadline, but if I can anonymize the api I will and send it.

I can tell you that the number of DataTypes is in the hundreds. Endpoints is also very in the hundreds. I did pull the Datatypes into some 20 libraries (not necessarily permanent, just to reduce scrolling). The Initial version of the API was pulled from .Net using the RAML .Net Tools to autogenerate.

the reason not using as is, There are some aspects of the definition that are incomplete or DataTypes poorly named (though as I am learning things, I have poorly named a few things - a refactor in my future ;) )

@ddenisenko

This comment has been minimized.

Show comment
Hide comment
@ddenisenko

ddenisenko Feb 14, 2017

Contributor

We couldn't reproduce the old case that we had. So we really need RAML example to reproduce.

Contributor

ddenisenko commented Feb 14, 2017

We couldn't reproduce the old case that we had. So we really need RAML example to reproduce.

@wbkoetsier

This comment has been minimized.

Show comment
Hide comment
@wbkoetsier

wbkoetsier Apr 10, 2017

Like sonicdivx our RAML file is not publicly available. But it contains some 1900 lines, >200 data types and I think >100 endpoints. There's a lot of inheritance between the types.

Typing has become so slow that I can't use this editor anymore. When I type just a few characters, it will take seconds before they appear on the screen. When I keep typing, for example a long sentence, it might take up to 30 seconds or more before appearing.

The completion function is very slow as well. It takes seconds for the context menu to appear. Once it has, selecting a word is as fast as it is supposed to be. But once selected it takes time to appear.

Validation is very slow as well. Sometimes it hangs, an error for a corrected mistake will not go away until a restart.

Menus and search functionality (ctrl-F) do not slow down, neither does scrolling or navigation to a type or endpoint using the editor tools.

Restarting Atom doesn't help, neither does closing the editor tools or console or any split window or any other open file at startup (or later on).

Based on the above I would say it's related to the validation.

I'm running Atom 1.15.0 x64, API-Workbench 0.8.44 (and linter 2.1.2 with linter-ui-default 1.2.2, intentions 1.1.2 and busy-signal 1.3.0) on Windows 10 (x64, Intel i7, more than enough RAM).

If there really is no other way, I might be persuaded to share (not publicly of course) our RAML file for the purpose of solving this issue. @sonicdivx did you make your deadline and are you able to share an anonymised version of your file like you said? That would very much be my preference, since our API will not become open source for a long time to come (if ever). Incompleteness or poor naming should not affect solving this issue, I'd say don't worry about it.

#164 seems related?

wbkoetsier commented Apr 10, 2017

Like sonicdivx our RAML file is not publicly available. But it contains some 1900 lines, >200 data types and I think >100 endpoints. There's a lot of inheritance between the types.

Typing has become so slow that I can't use this editor anymore. When I type just a few characters, it will take seconds before they appear on the screen. When I keep typing, for example a long sentence, it might take up to 30 seconds or more before appearing.

The completion function is very slow as well. It takes seconds for the context menu to appear. Once it has, selecting a word is as fast as it is supposed to be. But once selected it takes time to appear.

Validation is very slow as well. Sometimes it hangs, an error for a corrected mistake will not go away until a restart.

Menus and search functionality (ctrl-F) do not slow down, neither does scrolling or navigation to a type or endpoint using the editor tools.

Restarting Atom doesn't help, neither does closing the editor tools or console or any split window or any other open file at startup (or later on).

Based on the above I would say it's related to the validation.

I'm running Atom 1.15.0 x64, API-Workbench 0.8.44 (and linter 2.1.2 with linter-ui-default 1.2.2, intentions 1.1.2 and busy-signal 1.3.0) on Windows 10 (x64, Intel i7, more than enough RAM).

If there really is no other way, I might be persuaded to share (not publicly of course) our RAML file for the purpose of solving this issue. @sonicdivx did you make your deadline and are you able to share an anonymised version of your file like you said? That would very much be my preference, since our API will not become open source for a long time to come (if ever). Incompleteness or poor naming should not affect solving this issue, I'd say don't worry about it.

#164 seems related?

@ddenisenko

This comment has been minimized.

Show comment
Hide comment
@ddenisenko

ddenisenko Apr 10, 2017

Contributor

Based on the above I would say it's related to the validation.

This is correct. Parsing is slow for big APIs, and anything related to parsing (not only validation) is slowed down. We will soon make available a prototype of API Workbench client for RAML Server. It's a fork of API Workbench, which uses RAML Server for validation, completion, and most other features. This prototype does not have parsing being faster, but it has parsing being performed in the background, so it does not slow down user typing.

Contributor

ddenisenko commented Apr 10, 2017

Based on the above I would say it's related to the validation.

This is correct. Parsing is slow for big APIs, and anything related to parsing (not only validation) is slowed down. We will soon make available a prototype of API Workbench client for RAML Server. It's a fork of API Workbench, which uses RAML Server for validation, completion, and most other features. This prototype does not have parsing being faster, but it has parsing being performed in the background, so it does not slow down user typing.

@sonicdivx

This comment has been minimized.

Show comment
Hide comment
@sonicdivx

sonicdivx Apr 10, 2017

That sounds great. Where should we be looking for this to test it. We are gearing up to have several teams start RAML specs so would like to get an environment setup as soon as possible.

Thanks

sonicdivx commented Apr 10, 2017

That sounds great. Where should we be looking for this to test it. We are gearing up to have several teams start RAML specs so would like to get an environment setup as soon as possible.

Thanks

@sichvoge

This comment has been minimized.

Show comment
Hide comment
@sichvoge

sichvoge Apr 10, 2017

Contributor

@sonicdivx we will publish it into a branch inside this repo, probably with the wip/ prefix inside the branch name. I will update everyone with another issue with names and how to give feedback.

Contributor

sichvoge commented Apr 10, 2017

@sonicdivx we will publish it into a branch inside this repo, probably with the wip/ prefix inside the branch name. I will update everyone with another issue with names and how to give feedback.

@wbkoetsier

This comment has been minimized.

Show comment
Hide comment
@wbkoetsier

wbkoetsier commented Apr 11, 2017

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment