Bug 63000 - Slow parsing (invalid area?)
Summary: Slow parsing (invalid area?)
Status: RESOLVED FIXED
Alias: None
Product: quanta
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: HI major
Target Milestone: ---
Assignee: András Manţia
URL:
Keywords:
: 66977 72163 73741 73753 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-08-20 11:18 UTC by palantir
Modified: 2004-06-01 16:48 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Using this file you should see the described problems (434 bytes, text/plain)
2003-08-20 11:19 UTC, palantir
Details

Note You need to log in before you can comment on or make changes to this bug.
Description palantir 2003-08-20 11:18:20 UTC
Version:           3.2-CVS-1 (using KDE 3.1.2)
Installed from:    compiled sources
Compiler:          gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
OS:          Linux (i686) release 2.4.20-8

When editing some PHP documents I notice an *impressive* slowdown during editing of certain parts of those files. This makes quanta almost unusable...
This is the standard output while typing in an area where there are no swlowdowns:

Quanta: Invalid area: 21,49,23,0
Quanta: Rebuild: 1 ms
Quanta: Invalid area: 23,4,23,0
Quanta: Parsing time (34 lines): 23 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 21,49,23,0
Quanta: Rebuild: 1 ms
Quanta: Invalid area: 23,4,23,0
Quanta: Parsing time (34 lines): 26 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 21,49,23,0
Quanta: Rebuild: 1 ms
Quanta: Invalid area: 23,4,23,0
Quanta: Parsing time (34 lines): 24 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 21,49,23,0
Quanta: Rebuild: 1 ms
Quanta: Invalid area: 23,4,23,0
Quanta: Parsing time (34 lines): 25 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 21,49,23,0
Quanta: Rebuild: 1 ms
Quanta: Invalid area: 23,4,23,0
Quanta: Parsing time (34 lines): 25 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 21,49,23,0
Quanta: Rebuild: 1 ms
Quanta: Invalid area: 23,4,23,0
Quanta: Parsing time (34 lines): 25 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 21,49,23,0
Quanta: Rebuild: 1 ms
Quanta: Invalid area: 21,49,23,0
Quanta: Rebuild: 1 ms

This is the stdoutput on areas WITH slowdowns:
Quanta: TagName: input
Quanta: Invalid area: 30,7,30,0
Quanta: Parsing time (32 lines): 24 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 29,76,28,1
Quanta: Parsing time (32 lines): 24 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 29,76,28,1
Quanta: Parsing time (32 lines): 28 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 29,76,28,1
Quanta: Parsing time (32 lines): 24 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 29,76,28,1
Quanta: Parsing time (32 lines): 25 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 29,76,28,1
Quanta: Parsing time (32 lines): 23 ms
Quanta: External parser: 0 ms
Quanta: Invalid area: 29,76,28,1
Quanta: Parsing time (32 lines): 23 ms
Quanta: External parser: 0 ms

This happens for example while typing within this tag <input type="button" name="do_nothing" value="Leave account as is"
onClick="TYPE HERE">

If on the next screen of the bug wizard there is an "attach file" button I will enclose the file I am using... ;-)
Comment 1 palantir 2003-08-20 11:19:56 UTC
Created attachment 2283 [details]
Using this file you should see the described problems
Comment 2 András Manţia 2003-08-22 18:01:06 UTC
Subject: Re:  New: Slow parsing (invalid area?)

The bug is known, the fix is in works, but it's not a one day job.

Andras


Comment 3 András Manţia 2003-11-11 12:20:38 UTC
It's really a major bug and I just started to work on. Hopefully it will be ready during this week, beginning of next week.
Comment 4 András Manţia 2003-11-13 15:16:25 UTC
*** Bug 66977 has been marked as a duplicate of this bug. ***
Comment 5 FACORAT Fabrice 2004-01-20 15:12:58 UTC
On latest quanta rpms ( kde 3.2 rc1 ) I still have this kind of problem. I don' know if this is related to invalid region, but sometimes I encounter massive slowdown of quanta when editing large file ( more than 200 lines ). I'm developping in PHP and often I may end up with very large files ( 500+ lines ).

On top of that I try disabling autocompletion, as noted in others reports, but unfortunately this doesn't really help. it was just slighty better but stil unusable. With kate there is no slowdown.

I'm using my own personnal color scheme.
Comment 6 András Manţia 2004-01-20 17:57:33 UTC
Subject: Re:  Slow parsing (invalid area?)

I know. I you have big PHP parts, it is still slow. I don't know when exactly 
I can fix it completely. :-( I'm trying it, maybe it will ready for 3.2 
final, otherwise in an upcoming BE release.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQFADV3hTQdfac6L/08RAl0lAKCNmpCxublxZnZUsmvyMZD1u82kWQCeLnna
g0NIst6vq5MTkcsmqMnJ/j0=
=6yj8
-----END PGP SIGNATURE-----

Comment 7 FACORAT Fabrice 2004-01-26 12:50:40 UTC
I just hope i will not have to switch to kate or bluefish for my PHP dev :( 
snif
Comment 8 András Manţia 2004-01-26 17:47:18 UTC
Subject: quanta/quanta

CVS commit by amantia: 

Experimental delayed reparsing. This should make the interface more responsive. 
Bug reporters: can you update/get Quanta from CVS and try it (and report back)?
Information about how to get it from CVS are in the README file (and at  http://developer.kde.org/source/). Note, the executable name is "quanta_be" for the HEAD CVS version.

Nicolas, can this cause problems in Kafka? The main idea is that the document is reparsed only after there was no keypress for some time. If somewhere an up-to-date node tree is needed, the parser->rebuild() must be called manually (see e.g QuantaView::slotEditCurrentTag). If it causes too much problem for you, we can revert, although the other alternative is threading (parsing in background), which may lead to better performance, but involves more code change.

CCMAIL: 63000@bugs.kde.org
CCMAIL: quanta@kde.org
CCMAIL: quanta-devel@kde.org
CCMAIL: f.faber-pro@ifrance.com


  M +9 -0      document.cpp   1.242
  M +1 -1      quanta.cpp   1.417
  M +1 -1      quanta_init.cpp   1.401
  M +4 -2      quantaview_slots.cpp   1.161
  M +6 -11     parser/parser.cpp   1.164
  M +4 -2      parser/parser.h   1.54


--- quanta/quanta/document.cpp  #1.241:1.242
@@ -1846,4 +1846,12 @@ void Document::slotTextChanged()
 void Document::slotDelayedTextChanged()
 {
+   if (typingInProgress)
+   {
+    // kdDebug(24000) << "Reparsing delayed!" << endl;
+     parser->setParsingNeeded(true);
+     QTimer::singleShot(250, this, SLOT(slotDelayedTextChanged()));
+     reparseEnabled = false;
+     return;
+   }
     uint line, column;
     QString oldNodeName = "";
@@ -1970,4 +1978,5 @@ void Document::slotDelayedTextChanged()
       quantaApp->getsTab()->slotReparse(this, baseNode , qConfig.expandLevel);
     }
+    reparseEnabled = true;
 }
 

--- quanta/quanta/quanta.cpp  #1.416:1.417
@@ -872,5 +872,5 @@ void QuantaApp::slotNewStatus()
     bool block=wTab->signalsBlocked();
     wTab->blockSignals(true);
-    //If we don't disable the parser, it wil parse page 0 and then reload kafka
+    //If we don't disable the parser, it will parse page 0 and then reload kafka
     //even if the signals are supposed to be blocked ;(
     parser->setParsingEnabled(false);

--- quanta/quanta/quanta_init.cpp  #1.400:1.401
@@ -270,5 +270,5 @@ void QuantaApp::initQuanta()
   connect(m_doc, SIGNAL(hideSplash()), SLOT(slotHideSplash()));
   connect(m_project, SIGNAL(hideSplash()), SLOT(slotHideSplash()));
-}
+  }
 
 

--- quanta/quanta/quantaview_slots.cpp  #1.160:1.161
@@ -80,7 +80,9 @@
 void QuantaView::slotEditCurrentTag()
 {
-  if (!writeExists()) return;
-
+  if (!writeExists()) 
+    return;
   Document *w = write();
+  if (parser->parsingNeeded())
+    baseNode = parser->rebuild(w);
   uint line,col;
   w->viewCursorIf->cursorPositionReal(&line, &col);

--- quanta/quanta/parser/parser.cpp  #1.163:1.164
@@ -62,4 +62,5 @@ Parser::Parser()
   m_quotesRx = QRegExp("\"|'");
   m_parsingEnabled = true;
+  m_parsingNeeded = true;
 }
 
@@ -434,4 +435,5 @@ Node *Parser::parse(Document *w)
   parseIncludedFiles();
   kdDebug(24000) << "External parser: " << t.elapsed() << " ms\n";
+  m_parsingNeeded = false;
  /*
  treeSize = 0;
@@ -531,12 +533,5 @@ Node *Parser::nodeAt(int line, int col, 
       if (node->child)
       {
-   /*     int nodeEl, nodeEc, childBl, childBc;
-        node->tag->endPos(nodeEl, nodeEc);
-        node->child->tag->beginPos(childBl, childBc);
-        if ( nodeEl < childBl || 
-             (nodeEl == childBl && nodeEc < childBc)) */
           node = node->child;
-        //else
-          //break;  
       } else
       {
@@ -880,5 +875,5 @@ void Parser::deleteNodes(Node *firstNode
 //    coutTree(m_node, 2);
   }
-  coutTree(m_node, 2);
+//  coutTree(m_node, 2);
 #ifndef BUILD_KAFKAPART
   Q_UNUSED(modifs);
@@ -1110,4 +1105,5 @@ Node *Parser::rebuild(Document *w)
 
  emit nodeTreeChanged();
+ m_parsingNeeded = false;
  return m_node;
 }

--- quanta/quanta/parser/parser.h  #1.53:1.54
@@ -70,5 +69,7 @@ public:
   /** Enable/Disable parsing. */
   void setParsingEnabled(bool enabled) {m_parsingEnabled = enabled;}
-  bool IsparsingEnabled() {return m_parsingEnabled;}
+  bool isParsingEnabled() {return m_parsingEnabled;}
+  void setParsingNeeded(bool needed) {m_parsingNeeded = needed;}
+  bool parsingNeeded() {return m_parsingNeeded;}
   /**
    * This function is ESSENTIAL : when one modify baseNode, one MUST use
@@ -109,4 +110,5 @@ private:
   QRegExp m_quotesRx;
   bool m_parsingEnabled;
+  bool m_parsingNeeded;
 
   void parseIncludedFile(const QString &fileName, DTDStruct *dtd);


Comment 9 FACORAT Fabrice 2004-01-26 18:52:49 UTC
I vote for the threaded parsing engine.

BTW I will try to compile CVS version when i will have time and try this solution as i'd rather have something usable for 3.2 release than something unusable.
Comment 10 András Manţia 2004-01-26 20:00:31 UTC
Subject: Re:  Slow parsing (invalid area?)

On Monday 26 January 2004 19:52, FACORAT Fabrice wrote:
> I vote for the threaded parsing engine.

Well, it may be better, but at this point it is too risky to do such a major 
change. And it's really a major one, which may have hidden impacts, causing 
misbehavior and crashes. The current solution, if it works, may be safely 
ported to the 3.2 branch.

Andras

Comment 11 András Manţia 2004-01-29 14:28:29 UTC
*** Bug 73753 has been marked as a duplicate of this bug. ***
Comment 12 András Manţia 2004-01-29 14:29:03 UTC
*** Bug 73741 has been marked as a duplicate of this bug. ***
Comment 13 Magnus Määttä 2004-02-04 06:44:45 UTC
I'm experiencing this too and I'm using BE built from CVS two days ago..

Quanta: External parser: 0 ms
Quanta: Parsing time (597 lines): 1238 ms
Quanta: External parser: 0 ms
Quanta: Parsing time (597 lines): 972 ms
Quanta: External parser: 0 ms
Quanta: Parsing time (597 lines): 954 ms
Quanta: External parser: 0 ms
Quanta: Parsing time (597 lines): 1006 ms
Quanta: External parser: 0 ms
Quanta: Parsing time (597 lines): 1081 ms


This makes it *very* hard to work on projects. Well, it makes it useless for projects since projects usually have large files.
Comment 14 András Manţia 2004-02-04 10:09:35 UTC
Subject: Re:  Slow parsing (invalid area?)

On Wednesday 04 February 2004 07:44, Magnus Määttä wrote:
> I'm experiencing this too and I'm using BE built from CVS two days ago..

Hm, can I get your file (in private)? In BE from kdewebdev it should be way 
faster.

Andras

Comment 15 András Manţia 2004-02-07 20:57:48 UTC
Subject: Slow parsing?

Hi girls and boys,

 Even since 3.2 alpha came out one of the biggest complaints was that in case 
of PHP files, typing is slow and Quanta just feels sluggish. Until now I just 
couldn't find a good way that can solve this situation. Yesterday an idea 
came to my mind and I implemented it. The base of the idea is lightening the 
parser code and doing some jobs only when it's really needed. In this case, 
so detailed parsing (of PHP/script areas) is done when the structure tree is 
displayed or updated instead during every keypress. The results? I got a test 
php file, which on my Athlon XP 2000+ took 2600ms to parse. This means that 
Quanta was not responsive for 2.5 secons if you were not typing continously 
(took a break of 250ms). In case of Quanta 3.2.0 this delay happened after 
_every_ keypress. Currently parsing of the same file takes in average 34ms. 
This is more than 75x faster and should make Quanta usable on most machines.
 Of course, as the code is still executed in other place, it means that 
refreshing of the structure tree is slower. The solution is:
- - switch away of the structure tree if you don't need it
- - turn off Instant Update in Configure Quanta->Parser
- - increase the refresh frequency in the same place

The new code is only in HEAD, in the kdewebdev module.

I'm waiting your feedback and report, and sorry about writing a general mail 
and in English. ;-)

Andras


Comment 16 Magnus Määttä 2004-02-08 07:30:32 UTC
I just had to push it even more to see if it really was fixed.

Quanta: Rebuild started.
Quanta: Invalid area: 0,0,13441,0
Quanta: Rebuild: 625 ms
Quanta: Rebuild started.
Quanta: Parsing time (13441 lines): 455 ms
Quanta: External parser: 0 ms
Quanta: Rebuild started.
Quanta: Parsing time (13441 lines): 517 ms
Quanta: External parser: 0 ms
Quanta: Rebuild started.

Usually you *never* have 13k lines of code in one file, if you do, you're probably doing something wrong or have some very strange stuff..

Whatever you change, it fixed it! =)

Now is it possible to make the inactivity timer value user configurable ?
So I don't have to patch my source to add a 15 second delay. I don't need it rebuilt often at all..

Thanks for the fix =)
Comment 17 András Manţia 2004-02-08 09:32:32 UTC
Subject: Re:  Slow parsing (invalid area?)

On Sunday 08 February 2004 08:30, Magnus Määttä wrote:
> So I don't have to patch my source to add a 15 second delay. I don't need
> it rebuilt often at all..

 But how does it behave with the default 250ms? I'm trying to avoid a new 
configuration option.

Andras

Comment 18 Magnus Määttä 2004-02-09 02:40:34 UTC
My bad, I should have changed to default first..
It works fine with the default value.. So no need to change it..
Comment 19 rgpublic 2004-02-18 23:22:19 UTC
Please include this in 3.2.1 if possible.
I'm really missing Quanta's PHP auto completion since I've
upgraded to 3.2.0. Right now I can only use Kate because
of this bug. It renders Quanta completely unusable for me :-(
Comment 20 András Manţia 2004-02-25 18:18:31 UTC
*** Bug 72163 has been marked as a duplicate of this bug. ***
Comment 21 András Manţia 2004-02-27 14:31:53 UTC
CVS commit by amantia: 

This big commit contains the most important fixes backported from HEAD, including the fix for the "slow parsing & typing" problem (#63000), a startup performance enhancher, reducing of memory usage, fixes renaming and inserting of new files in project tree view and some usability fixes, which does not require string changes.
Due to the changes made in HEAD, some code restructuration of the code was needed here as well, otherwise it'd be too error prone to backport the fixes as the difference was too big between HEAD and BRANCH. I've tried to make sure that no string changes were backported. 
 The changes were throughoutly tested in HEAD in the last week and it seems that no critical bugs are present now.

CCMAIL: 63000-done@bugs.kde.org


  A            quanta/dtds.cpp   1.1.2.1 [GPL (v2+)]
  A            quanta/dtds.h   1.1.2.1 [GPL]
  A            quanta/data/icons/22x22/css.png   1.1.2.1
  A            quanta/parser/parsercommon.cpp   1.1.2.1 [GPL (v2+)]
  A            quanta/parser/parsercommon.h   1.1.2.1 [GPL (v2+)]
  A            quanta/parser/saparser.cpp   1.1.2.1 [GPL (v2+)]
  A            quanta/parser/saparser.h   1.1.2.1 [GPL (v2+)]
  A            quanta/project/projecturl.h   1.1.2.1 [GPL (v2+)]
  M +5 -0      ChangeLog   1.205.2.15
  M +1 -1      quanta/Makefile.am   1.96.2.3
  M +122 -125  quanta/document.cpp   1.240.2.4
  M +8 -7      quanta/document.h   1.99.2.1
  M +1 -1      quanta/kqapp.cpp   1.43.2.3
  M +137 -274  quanta/quanta.cpp   1.414.2.7
  M +9 -33     quanta/quanta.h   1.190.2.1
  M +73 -777   quanta/quanta_init.cpp   1.399.2.4
  M +124 -47   quanta/quantacommon.cpp   1.73.2.1
  M +3 -6      quanta/quantacommon.h   1.59.2.1
  M +43 -48    quanta/quantadoc.cpp   1.130.2.2
  M +2 -2      quanta/quantadoc.h   1.37.4.1
  M +2 -2      quanta/quantaview.cpp   1.70.2.3
  M +4 -2      quanta/quantaview.h   1.77.2.1
  M +24 -24    quanta/quantaview_slots.cpp   1.159.2.4
  M +2 -3      quanta/resource.h   1.37.2.1
  M +1 -1      quanta/data/icons/22x22/Makefile.am   1.22.2.1
  M +5 -4      quanta/dialogs/abbreviation.cpp   1.16.2.1
  M +1 -1      quanta/dialogs/abbreviation.h   1.5.4.1
  M +6 -2      quanta/parser/Makefile.am   1.18.4.1
  M +1 -1      quanta/parser/dtdparser.cpp   1.15.2.1
  M +22 -7     quanta/parser/node.cpp   1.39.2.2
  M +3 -2      quanta/parser/node.h   1.32.2.1
  M +337 -1081 quanta/parser/parser.cpp   1.159.2.6
  M +27 -61    quanta/parser/parser.h   1.53.2.3
  M +27 -26    quanta/parser/qtag.h   1.53.2.1
  M +5 -5      quanta/parser/tag.cpp   1.52.2.3
  M +3 -2      quanta/parser/tag.h   1.38.2.2
  M +3 -3      quanta/parts/kafka/kafkacommon.cpp   1.26.2.2
  M +3 -3      quanta/parts/kafka/kafkacommon.h   1.20.2.2
  M +1 -1      quanta/parts/kafka/wkafkapart.cpp   1.49.2.3
  M +1 -1      quanta/parts/kafka/wkafkapart.h   1.26.2.2
  M +5 -5      quanta/plugins/quantaplugin.cpp   1.16.2.1
  M +20 -1     quanta/plugins/spellchecker.h   1.3.4.1
  M +175 -221  quanta/project/project.cpp   1.136.2.1
  M +44 -30    quanta/project/project.h   1.50.2.1
  M +21 -24    quanta/project/projectupload.cpp   1.49.2.1
  M +1 -2      quanta/project/projectupload.h   1.21.2.1
  M +1 -1      quanta/project/rescanprj.cpp   1.18.4.1
  M +3 -2      quanta/project/rescanprj.h   1.10.4.1
  M +2 -2      quanta/tagdialogs/tableeditor.ui   1.26.2.1
  M +5 -6      quanta/tagdialogs/tableeditor.ui.h   1.34.2.4
  M +12 -7     quanta/tagdialogs/tagxml.cpp   1.24.2.1
  M +2 -4      quanta/tagdialogs/tagxml.h   1.9.4.1
  M +33 -29    quanta/toolbar/tagaction.cpp   1.77.2.1
  M +79 -33    quanta/treeviews/filestreeview.cpp   1.64.2.2
  M +18 -4     quanta/treeviews/filestreeview.h   1.29.2.1
  M +150 -77   quanta/treeviews/projecttreeview.cpp   1.63.2.2
  M +49 -22    quanta/treeviews/projecttreeview.h   1.26.2.1
  M +7 -2      quanta/treeviews/scripttreeview.cpp   1.15.2.1
  M +121 -3    quanta/treeviews/scripttreeview.h   1.8.4.1
  M +1 -1      quanta/treeviews/structtreetag.cpp   1.34.2.1
  M +0 -2      quanta/treeviews/structtreetag.h   1.15.4.1
  M +144 -156  quanta/treeviews/structtreeview.cpp   1.86.2.3
  M +23 -4     quanta/treeviews/structtreeview.h   1.23.2.1
  M +7 -3      quanta/treeviews/tagattributetree.cpp   1.34.2.2
  M +1 -1      quanta/treeviews/tagattributetree.h   1.16.2.1
  M +108 -53   quanta/treeviews/templatestreeview.cpp   1.64.2.3
  M +62 -8     quanta/treeviews/templatestreeview.h   1.18.2.1



Comment 22 Christopher V. Browne 2004-06-01 16:48:21 UTC
Since I began using KDE 3.2 on FC1 and higher... when working on PHP
scripts... Quanta just inexplicably freezes and I can no longer work in
it. CPU usage goes up to 100% 
* this didn't start happening until I used KDE 3.2+

Currently using latest I'm using is FC2 kernel-2.6.5-1.358
Quanta 3.2.2
KDE 3.2.2-7.0.2.kde