Alex,
Confirmed, that took care of all the failures. Thanks for the quick resolution.
On Sep 22, 2008, at 09:04PM, Alexey Panchenko wrote: Shelby,
I have missed the changes to RubyClassDeclaration (the change is similar to the RubyModuleDeclaration). Tests pass now.
Regards, Alex On Tue, Sep 23, 2008 at 06:45, Shelby Sanders <ssanders@xxxxxxxxxxxx> wrote: Alex, Is the "org.eclipse.dltk.ruby.core.tests.AllTests" suite passing for you? The following are all failing for me, because the assertion is expecting one less reference than what is reported: RubySearchTests.testReferences RubySearchTests.testAllOccurences RubyFullNameSearchTests.testFullTypeReferenceSearch RubyFullNameSearchTests.testSuperClassReferenceSearch1 RubyFullNameSearchTests.testSuperClassReferenceSearch2 There is also one of our internal tests now failing for the same reason. Thank You, Shelby Sanders On Sep 22, 2008, at 06:47AM, Alex Panchenko wrote: Shelby, I had an idea on the weekend how the performance could be fixed, so I have committed it. Regards, Alex Shelby Sanders wrote: Alex, Oh, OK. Sorry, I didn't pay enough attention to the subject. Yes, I'll definitely take a look, next week. It kind of makes sense that that is showing up as a hotspot now, because I added a bunch of Type Reference scenarios. Thank You, Shelby Sanders On Sep 19, 2008, at 05:22PM, Alex Panchenko wrote: Shelby, Probably my message was not clear enough (it was late here when I have written the message). The name of the problem class is in the subject. It is used in different places. I have just noticed the long operations when they are performed in the UI thread - e.g. saving the file. Please see the lines where I have measured the save time: --- src/org/eclipse/dltk/internal/ui/editor/SourceModuleDocumentProvider.java 18 Sep 2008 09:20:02 -0000 1.32 +++ src/org/eclipse/dltk/internal/ui/editor/SourceModuleDocumentProvider.java 20 Sep 2008 00:09:57 -0000 @@ -1356,8 +1356,11 @@ protected void execute(IProgressMonitor monitor) throws CoreException { + final long start = System.currentTimeMillis(); commitWorkingCopy(monitor, element, (SourceModuleInfo) info, overwrite); + System.out.println("commitWorkingCopy " + + (System.currentTimeMillis() - start)); } For tests I have used the tk.rb file from standard ruby library. It is ~135k, so I have doubled its content to get file of the 270k size. Regards, Alex ----- Original Message ----- From: "Shelby Sanders" <ssanders@xxxxxxxxxxxx> To: "DLTK Developer Discussions" <dltk-dev@xxxxxxxxxxx> Sent: Saturday, September 20, 2008 1:50:38 AM GMT +06:00 Almaty, Novosibirsk Subject: Re: [Dltk-dev] RubySourceElementRequestor Alex, Could this be caused by the recent changes in ScriptEditor? Thank You, Shelby Sanders On Sep 19, 2008, at 09:44AM, Alex Panchenko wrote: Hi All, To Shelby Sanders: I am testing how the ruby editor operates with large files - I have done testing on 270Kb file. There is 9 times slowdown from this class compared to the previous version of it. Do you have plans to optimize the latest changes? Thanks, Alex _______________________________________________ dltk-dev mailing list dltk-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dltk-dev _______________________________________________ dltk-dev mailing list dltk-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dltk-dev _______________________________________________ dltk-dev mailing list dltk-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dltk-dev _______________________________________________ dltk-dev mailing list dltk-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dltk-dev _______________________________________________ dltk-dev mailing list dltk-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dltk-dev _______________________________________________ dltk-dev mailing list dltk-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dltk-dev <ATT00001.c>
|