jcompagner:
So try to keep everything local.
Johan,
Unfortunately, trying to keep everything local is not practical/possible in big projects. We need the ability to separate the code in logical modules to make it reusable and maintainable.
On the “very slow” part - it is very slow currently - the memory leak issue has been resolved but now the background “building workspace…” process which is triggered on every Save operation slows down the IDE and the code editor in particular. I am sure that for small solutions it may not be noticeable, but for big ones it is a constant pain. Even simple operations like selecting code fragments with the keyboard are ridiculously slow while the background build is going. In addition, working with the code editor while the background build is in progress causes some weird issues like code which the developer types in are overwritten/changed by the IDE. This happens even after increasing the IDE memory to 1GB. Currently, working with the code editor (which our developers are doing most of the time) is approximately 2x slower even after considering the assistance provided by the enhanced code completion which is a big help. Just timing how much it takes to complete several routine tasks (like making several code changes in 2-3 files and writing a new method) reveals that the productivity loss is a bit over 50% for us when it comes to writing the JavaScript code. I can only imagine that if nothing else changes in the Servoy IDE, as our project grows over time this productivity hit will even increase.
I understand that the product is still in beta phase and hopefully performance and optimization are the focus for the future builds. We will gladly provide any assistance to help with this process.
and what you describe about the performance is exactly the stuff that we can’t do anything more currently for resolving objects
that will make it a factor X slower.
so i don’t think it will be possible in 6 that you have this:
file1.js
function MyObject() {
this.x = “a string”
}
file2.js:
function AnotherObject() {
this.y = new forms.file1.MyObject();
}
and then in file3.js:
function test() {
var x = new forms.file2.AnotherObject();
x.y. << code completion here
}
i am afraid that this will not be happening in 6, that would completely kill the performance and use a lot of memory because everything must resolve to everything. (and it could also be circular when file1 also references something out of file2)
I will try to get more performance out of it before the final of 6. But i do need a large workspace that i guess should have a lot of dependencies between files. (and that is not easy to get)
Hi Johan,
I am noticing a degradation in the building speed of Servoy 5.2.x now our solution is growing and growing…
What can I do to stop it from becoming unworkable ?
Regards,
5.2 won’t change anymore in this area, the only thing you can do is work on smaller parts so only have a module and some other active and not the complete solution.
Hi Servoy,
When I try to use the code completion for certain forms, I am getting the message “Computation of proposals is too log. Please try again” (shows in red at the bottom of the IDE) and the code completion basically does not work. Trying gain does not seem to help. Why am I getting this message, what does it mean and how can it be resolved?
that should only happen when the code completion does cost more the 5 seconds to complete.
Which is quite long and shouldn’t happen. Do you have any errors in the eclipse log? (so the one in the workspace/.metadata)
jcompagner:
that should only happen when the code completion does cost more the 5 seconds to complete.
Which is quite long and shouldn’t happen. Do you have any errors in the eclipse log? (so the one in the workspace/.metadata)
No errors in the log file. The only abnormal thing there is related to the cheatsheets:
!ENTRY org.eclipse.ui.workbench 2 0 2011-04-20 05:00:02.658
!MESSAGE A handler conflict occurred. This may disable some commands.
!SUBENTRY 1 org.eclipse.ui.workbench 2 0 2011-04-20 05:00:02.658
!MESSAGE Conflict for 'AUTOGEN:::org.eclipse.ui.cheatsheets.actionSet/org.eclipse.ui.cheatsheets.actions.CheatSheetHelpMenuAction':
HandlerActivation(commandId=AUTOGEN:::org.eclipse.ui.cheatsheets.actionSet/org.eclipse.ui.cheatsheets.actions.CheatSheetHelpMenuAction,
handler=ActionDelegateHandlerProxy(null,org.eclipse.ui.cheatsheets.CheatSheetExtensionFactory:helpMenuAction),
expression=AndExpression(ActionSetExpression(org.eclipse.ui.cheatsheets.actionSet,org.eclipse.ui.internal.WorkbenchWindow@196b753),WorkbenchWindowExpression(org.eclipse.ui.internal.WorkbenchWindow@196b753)),sourcePriority=16640)
HandlerActivation(commandId=AUTOGEN:::org.eclipse.ui.cheatsheets.actionSet/org.eclipse.ui.cheatsheets.actions.CheatSheetHelpMenuAction,
handler=ActionDelegateHandlerProxy(null,org.eclipse.ui.cheatsheets.CheatSheetExtensionFactory:helpMenuAction),
expression=AndExpression(ActionSetExpression(org.eclipse.ui.cheatsheets.actionSet,org.eclipse.ui.internal.WorkbenchWindow@196b753),WorkbenchWindowExpression(org.eclipse.ui.internal.WorkbenchWindow@196b753)),sourcePriority=16640)
@Rob and dataset serialization
in Servoy 5.2.7i1 I have the same issue. The authenticator will no longer return a dataset. I hope this is fixed in 5.2.8? Currently I cannot debug 5.2.7i1, because I cannot log in ![:-(]( "Sad")
.
→ case closed; my installation was messed up; works in 5.2.7i1
Hi Servoy,
We are hitting some serious performance issues in the code editor. We have some .js files which contain about 200 methods and a few thousand lines of code (a big part of that however are the JSDoc comments) Working with those files in the script editor is close to impossible in the beta 1. Each save operation takes 20+ seconds, selecting code using the keyboard (Shift or Ctr+Shift and the arrow keys) take 2-3 seconds for each key stroke, selecting a method in the Outline pane takes 10+ seconds to refresh the script editor and display the selected method, the code completion takes 5+ seconds for each invocation, etc. Many times the whole IDE “freezes” for 5-7 seconds due to some background operations taking too long to complete - you can imagine what this does to a developer who is trying to work with a deadline. Unfortunately, some of these big files are for “base” forms which are used heavily by extending them, and the similar issues apply when working with the sub-forms. In other words, trying to work only with a specific module being activated and setting all JavaScript warnings to “Ignore” does not help. The issues are present on all developer machines with the max Servoy IDE memory configured to 1GB+
As far as we are concerned, these severe performance issues are completely unacceptable and hope to see them resolved soon.
Is there a way to completely disable the code-analysis and any additional background operations so our developers can continue to work albeit with reduced IDE code assistance until the performance issues are resolved?
what happens if you just turn of Build automatically?
(project menu)
jcompagner:
what happens if you just turn of Build automatically?
(project menu)
I turned off the automatic build and restarted the Servoy Developer. The change did not have a significant effect on the performance issue - the Save operation takes a bit less (about 12 seconds instead of 20) but everything else is like before - working in the script is still an endless waiting process.
rossent:
jcompagner:
what happens if you just turn of Build automatically?
(project menu)
I turned off the automatic build and restarted the Servoy Developer. The change did not have a significant effect on the performance issue - the Save operation takes a bit less (about 12 seconds instead of 20) but everything else is like before - working in the script is still an endless waiting process.
Servoy,
A few more things which may help you track down and resolve the issue:
I created a sample blank solution in a separate workspace where I copied the code from one of the big files which we have (it is a bit over 6000 LOC, with about 200 methods and 20 form variables where about 50% are JSDoc comments - of course, there are tons of warnings due to the missing references). With the automatic build enabled and the JavaScript code analysis settings set to the default values, I immediately saw the script editor performance to decrease drastically. The solution contains a single file and selecting code using Ctrl + Shift + Right Arrow takes about 1 second per key stroke! The same applies even if I try to select the code with the mouse. Using the Outline View, it takes about 1.5 seconds for the script editor to locate and display the method which I clicked on! If I add a few more files and modules, the thing becomes unusable. In other words, I can reproduce the performance issue event with an orders of magnitude smaller workspace - all it takes is a few large files in 4-5 modules to bring it to its knees. I am sure you should be able to reproduce this scenario quite easily.