Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > Visual C++ MFC > Syntax Edit
  New Posts New Posts RSS Feed - Syntax Edit is so slow that it is Unusable !
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Syntax Edit is so slow that it is Unusable !
 Post Reply Post Reply
Author
Message
  Topic Search Topic Search  Topic Options Topic Options
Tomasz View Drop Down
Senior Member
Senior Member


Joined: 05 August 2006
Status: Offline
Points: 109 		Post Options Post Options   Thanks (0) Thanks(0)   Quote Tomasz Quote  Post ReplyReply Direct Link To This Post Topic: Syntax Edit is so slow that it is Unusable !
    Posted: 19 December 2007 at 12:27pm
Rant on.
 
I hate to say that, but in current shape the Syntax Edit is UNUSABLE.
 
And I mean it. It is SO SLOW that it goes beyond imagination.
I have only ONE schema file that is 32 KB (kilobytes) long. It has 350 tags in total.
Now I am opening SyntaxEdit and trying to load 8KB (yes EIGHT kilobyte) file and how much does it take on dual core 2GHz CPU clock computer ?????
 
More than ONE second (actually close to 2 seconds). And it does that with opening each such file. And yes this is RELEASE BUILD.
Sorry guys but hugely bloated MS Word is many times faster !
 
Codejock - is this a joke or what???
2GHz dual core processor executes more 2 billions of operations per seconds.
The editor takes 2 BILLION operations to open 8KB file with 32K def ????
 
How bad coding is that??? What you guys doing ?? Do you really need to perform on average 50000 operations to load a single byte into the text editor???? Do you encrypt each byte with zillion-bit key length ? Or do these bytes play chess between each other ?? What kind of task requires that amount of processing?
 
It is a shame, big shame on Codejock. The rest of the library is relatively fast but the editor is a MAJOR FAILURE when it comes to speed.
 
Sorry to say that but in current shape the control is unusable.
 
This control needs to be speeded up by FACTOR OF 10 AT LEAST. 200 million operations should be perfectly enough to load 8K even for very lousy coder writing in Basic.
 
Rant off.
 
Regards,
Tomasz
Back to Top
Tomasz View Drop Down
Senior Member
Senior Member


Joined: 05 August 2006
Status: Offline
Points: 109 		Post Options Post Options   Thanks (0) Thanks(0)   Quote Tomasz Quote  Post ReplyReply Direct Link To This Post Posted: 19 December 2007 at 12:54pm
I have one proposal for making it quicker without major rewrite
- add ability to store Lex configuration into BINARY file in "fast-load" format that is later used for during any further opening without need to re-parse class definition files over and over again.
 
Second proposal:
use yylex/yyparse parser generator for class definition parser instead of your own. yylex/yyparse produces parsers that are several orders of magnitude faster than your own invention.
Back to Top
Tomasz View Drop Down
Senior Member
Senior Member


Joined: 05 August 2006
Status: Offline
Points: 109 		Post Options Post Options   Thanks (0) Thanks(0)   Quote Tomasz Quote  Post ReplyReply Direct Link To This Post Posted: 19 December 2007 at 1:17pm
ONe more question to Codejock:
why on earth if Syntax Edit is used in MDI application it re-reads and re-parses configuration file over and over again with opening every new document? Why don't you parse once and keep definition in memory???
CXTPSyntaxEditBufferManager is created each time and it calls ReloadConfig all the time which in succession causes calling LoadTextScheme which is the biggest time eater! And is doing so with each and every document open.
Back to Top
sserge View Drop Down
Moderator Group
Moderator Group


Joined: 01 December 2004
Status: Offline
Points: 1297 		Post Options Post Options   Thanks (0) Thanks(0)   Quote sserge Quote  Post ReplyReply Direct Link To This Post Posted: 19 December 2007 at 5:37pm
Well, we know that it's quite slow. And yes, you might be correct that the core parser should be replaced there at all.

However, even in a current state, do not forget that parsing itself is working in a background thread and doesn't prevent you from actually doing editing/reading/anything with your text file. All that you see on the screen is parsed right away.

--
WBR,
Serge
Back to Top
Tomasz View Drop Down
Senior Member
Senior Member


Joined: 05 August 2006
Status: Offline
Points: 109 		Post Options Post Options   Thanks (0) Thanks(0)   Quote Tomasz Quote  Post ReplyReply Direct Link To This Post Posted: 19 December 2007 at 6:10pm
ROTFL. You are dreaming. In its current shape it completely prevents me
from even SEEING the control because the entire application is DEAD LOCKED and not responding for 1+ second while *scheme* is being loaded.
 
Your response clearly shows that you did NOT even try to use this control in real world application. It does NOT matter that parsing of the text is in separate thread when loading a _SCHEME_ is slow and this happens PRIOR to parsing actual file !

If you OPEN the document in MDI application using your syntax edit it CREATES the SyntaxEdit control. During creation it PARSES THE SCHEME each and every time PRIOR to doing ANYTHING else. And it LOCKS UP entire application for that time.

 
So your second thread does not even start, because the control did NOT yet show up - it is BUSY "initializing" itself.
 
There is a good saying that company shoud "eat its own dog food". (i.e. use its own products). It means that you should actually try to USE your control in real-world (for example for editing XTremeToolkit sources) for a couple of weeks and you will quickly
see all its drawbacks.
Back to Top
AndreiM View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 18 August 2007
Status: Offline
Points: 132 		Post Options Post Options   Thanks (0) Thanks(0)   Quote AndreiM Quote  Post ReplyReply Direct Link To This Post Posted: 20 December 2007 at 6:08am
Hello Tomasz,
In regard to reloading configuration every time - this is an issue. It happens if you call GetEditCtrl().SetConfigFile(...) not from your view class constructor (for example from OnCreate handler or other) or in some other cases. In our sample GetEditCtrl().SetConfigFile(...) called from CMDITextEditorView constructor and configuration files loaded only once.
 
To fix this please change implementation of CXTPSyntaxEditBufferManager::SetConfigFile like shown below and rebuild Toolkit.
Thanks for your help to find this issue.
 


BOOL CXTPSyntaxEditBufferManager::SetConfigFile(LPCTSTR szPath)
{
 if (!m_ptrLexConfigurationManager)
  return FALSE;
 
 CString strCfgFile0 = m_ptrLexConfigurationManager->GetConfigFile(); 
  
 if (strCfgFile0.CompareNoCase(szPath) != 0)
  m_ptrLexConfigurationManager->ReloadConfig(szPath);


 


 return TRUE;
}
 
About store/load schemas in binary format,
I also think about such way. But on my mind this have sense for big and complex schema files or for big amount of schemas. For current configuration more effective to use delay schema loading (it is implemented in 11.2.2). Now all schemas just readed at startup (this fast) but each schema builded (only once) when it need to parse document.
Back to Top
Tomasz View Drop Down
Senior Member
Senior Member


Joined: 05 August 2006
Status: Offline
Points: 109 		Post Options Post Options   Thanks (0) Thanks(0)   Quote Tomasz Quote  Post ReplyReply Direct Link To This Post Posted: 21 December 2007 at 12:59pm
Thank you for the answer.
 
My code was already using SetConfigFile inside my view CONSTRUCTOR and only there, and it still loaded the config file with each view creation in the MDI application.
 
But I will check the library change proposed and will get back to you if it helps or not.
Back to Top
Tomasz View Drop Down
Senior Member
Senior Member


Joined: 05 August 2006
Status: Offline
Points: 109 		Post Options Post Options   Thanks (0) Thanks(0)   Quote Tomasz Quote  Post ReplyReply Direct Link To This Post Posted: 14 February 2008 at 6:22pm
Sorry to say, but I downloaded 11.2.2 and it is NOT fixed.
 
I also tried this code:




BOOL CXTPSyntaxEditBufferManager::SetConfigFile(LPCTSTR szPath)
{
 if (!m_ptrLexConfigurationManager)
  return FALSE;
 
 CString strCfgFile0 = m_ptrLexConfigurationManager->GetConfigFile(); 
  
 if (strCfgFile0.CompareNoCase(szPath) != 0)
  m_ptrLexConfigurationManager->ReloadConfig(szPath);



 



 return TRUE;
}
 
And it is as slow as it was. There is absolutely NO difference.
Your schema loading is PAINFULLY SLOW. Each time control is created it takes the same long time.
Reproduction steps:
Using MDI editor:
1. Open the file (....long time to initialize...)
2. Close the document (not the program)
3. Open the same file again (.... again long time to initialize)
 
So this workaround does not work. RE-implementing it from the scratch is ESSENTIAL to make this control usable.
My schema has 34KB and 1227 lines. It takes two seconds to load on 2GHz CPU. You need to speed it up by factor of 10 to make it usable.
When user clicks to open the file and it takes 2 seconds for control to show up on very fast computer the user would throw away such application. Nowadays MS Word loads faster than your control.
 
I have sent my schema to support for you to check and see on  your end how slow it loads.
 
 
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.04
Copyright ©2001-2021 Web Wiz Ltd.

This page was generated in 0.188 seconds.