»
« home   paste   Anonymous | Login | Signup for a new account 01-24-2019 04:58 CET
 
* X »
«
GeSHi - Generic Syntax Highlighter Syntax Coloriser for PHP
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000058 [GeSHi] core tweak always 01-02-06 19:33 01-26-07 09:29
Reporter nigel View Status public  
Assigned To nigel
Priority normal Resolution open  
Status assigned   Product Version 1.1.1alpha3
Summary 0000058: Analyse GeSHiCodeContext for speed optimisations
Description Since this is the place where much of the time is spent.

Possible things to do could be:

  * removing the method that builds the keywords into a good form
  * re-organising list or binary tree for keywords
Additional Information
Attached Files

- Relationships
related to 0000089closed nigel geshi_get_position() optimisations for regex matching 

- Notes
(0000450)
nigel
09-17-06 22:07

There's a patch for 1.0.X that has shown much success when organising the keywords into a regex "trie", which might be work investigating.
 
(0000461)
BenBE
09-21-06 05:32

Do you mean something like

preg_match('/' . implode('|', $keywordarray) . '/Uis', $subject)

to replace multiple lookups of a string-table with only searching for one long preg_match? Or do I misunderstand you?
 
(0000463)
nigel
09-21-06 09:18

That's sort of what the trie does. It's more complicated than that, involving giving the regex plenty of ways to get out of a match that fails. See the 1.0.X source and the wikipedia page on Tries.

It's funny that it turns out to be faster, even though it's just one massive regex. I don't know whether it will prove any good for 1.2 but we will see.
 
(0000470)
BenBE
01-26-07 03:48

My latest analysis showed (as the previous did already) that the main time GeSHi requires is used up in geshi_get_position (and the GeSHiCodeConext class.

What about caching RegExp results and a strpos\"stripos" cache of all matches for the given context. Thus finding the next match would only require looking up one element in an ordered array. The disadvantage of this is, that huge sources could require a lot of memory to build this array.
 
(0000472)
nigel
01-26-07 09:29

That patch hasn't been applied to 1.0.X yet, I am planning to apply it to trunk at some point. But you're right about the idea.
 

- Issue History
Date Modified Username Field Change
01-02-06 19:33 nigel New Issue
01-02-06 19:33 nigel Status new => assigned
01-02-06 19:33 nigel Assigned To  => nigel
09-13-06 12:55 BenBE Relationship added related to 0000089
09-17-06 22:07 nigel Relationship added child of 0000091
09-17-06 22:07 nigel Note Added: 0000450
09-18-06 00:11 nigel Relationship deleted child of 0000091
09-21-06 05:32 BenBE Note Added: 0000461
09-21-06 09:18 nigel Note Added: 0000463
01-26-07 03:48 BenBE Note Added: 0000470
01-26-07 09:29 nigel Note Added: 0000472

  


Mantis 1.0.0rc2[^]
Copyright © 2000 - 2005 Mantis Group
44 total queries executed.
32 unique queries executed.
Powered by Mantis Bugtracker