Neil Hodgson wrote:
Scintilla's use of PropSet is very simple (32 keys are inserted by
SciTE) and hasn't appeared important in profiles. SciTE is heavier but
the main problem is not with hashed access but with file pattern based
properties which require exhaustive searches. Say the file 'hash.xx'
has been opened and it goes looking for a lexer as specified in one of
the lexer.<filepattern> properties lexer.*.cxx lexer.*.hh;*.xx and
lexer.*.js;*.html . It can't go searching for a particular hash
because the <filepattern> may contain more than one pattern. Therefore
it looks at every single property checking for the prefix "lexer." and
then whether the filename matches the rest of the key name. There are
various improvements that could be made to the data structure to
address this such as linking together all the keys with a particular
prefix. While the time taken to do these searches is noticeable in
profiles it has never been slow enough to look at fixing.
I probably misunderstood your response a couple back in this thread:
"You are probably thinking of PropSet which should probably be
turned into a real hash table as the data sets it is used on are much
larger than it was originally written for."
2) I packaged it in a very contained way - just replacing the previous
[inline] definition of PropSet::HashString in propset.h
About the only negative I have is that the code is longer and more
complex. For SinkWorld I used Python's string hash which is 7 line of
code.
The original HashString function body is 7 lines (too? is Python where
this came from?)... 3 obvious responses:
1) is line-count a good determinant in evaluating hash algos?
2) source code size/layout may not be a good indicator of the length
of runtime code paths
3) within reasonable limits, a few more instructions in the hash
function itself are well justified if you get fewer collisions
3) The legalities are discussed in some length by the author at
http://www.azillionmonkeys.com/qed/weblicense.html
By stripping the already quite sparse comments, I believe the borrowed
"raw source code" qualifies under the author's "derivative" license,
and Scintilla's own licensing terms do not invalidate this.
Interpreting the conditions is fun but it looks OK.
Indeed. ;)
...
Scintilla only uses simple key names (no filepatterns) and integer
values so could actually use a very simple implementation, moving the
full featured hash table into SciTE. I wouldn't mind decreasing the
'helper library' part of Scintilla (SString, PropSet, WordList, ...)
that are statically linked into client code since it complicates using
Scintilla.
So it looks like you weren't really looking for this... OK.
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scite-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scite-interest
