Syntax Edit - Syntax Edit is so slow that it is Unusable !

Syntax Edit is so slow that it is Unusable !

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Syntax Edit
Forum Description: Topics Related to Codejock Syntax Edit
URL: http://forum.codejock.com/forum_posts.asp?TID=9148
Printed Date: 11 December 2024 at 8:48pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: Syntax Edit is so slow that it is Unusable !

Posted By: Tomasz
Subject: Syntax Edit is so slow that it is Unusable !
Date 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

Replies:

Posted By: Tomasz
Date 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.

Posted By: Tomasz
Date 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.

Posted By: sserge
Date 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

Posted By: Tomasz
Date 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.

Posted By: AndreiM
Date 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.

-------------
Regards,
Andrei Melnik

Posted By: Tomasz
Date 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.

Posted By: Tomasz
Date 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.