| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
Slovak, Hungarian, Slovene, Bosnian, Croatian, Serbian, Romanian and Albanian
|
|
|
|
|
|
|
|
|
|
work for syncategorematic words yet
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
exper/EditShell; still buggy
|
|
|
|
|
|
|
|
matching in grammar compilation
|
|
|
|
|
|
current pgf server.
|
|
record patterns
|
|
|
|
|
|
|
|
|
|
Profiling the compilation of the OALD lexicon showed that 90-95% of the time was spent in topoSort. The old implementation was quadratic. Replaced this with O(E + V) implementation, in GF.Data.Relation. This gave a 10x speed-up (~ 25 sec instead of ~270 sec) for compiling ParseEng and OaldEng.
|
|
|
|
|
|
Profiling showed that when loading a large .gfo file, shareString was responsible for
15-18% of the CPU time, and a lot of the allocation. Since we already use ByteStrings for
reading the source files, shareString mostly has the effect of creating lots
of small ByteStrings instead of one large one. Since the plain size of the .gfo is seldom
a problem (unlike when it was read as a String), it is ok to keep the whole file
as one ByteString in RAM, and have all tokens point into that.
Profiling after the change showed 15-20% reduction in CPU time and in total allocation.
|
|
60% of the CPU time when reading a large .gfo file. Replacing BinTree by Data.Map reduced this to about 6%, which meant about 50% reduction in total CPU time.
|
|
|
|
|
|
variable they set, we just created zombies.
|
|
|
|
|
|
helps avoid clashed when running muyltiple gf servers on the same machine.
|
|
Without this, the Binary Word instance would be wrong on 64-bit machines.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
