Da się to zoptymalizować, gdyż w tej chwili robi alokację stringa z każdym pobraniem znaku. Jeśliby robić tą alokację na każdym słowie myślę, że byłoby zdecydowanie szybciej.
Hmm? Moze ja zle patrze, ale w zrodlach tego nie widze... alokacja jest robiona raz na slowo:
std::string cParser::readToken(bool ToLower, const char *Break)
{
std::string token = "";
(...)
char c;
do
{
while (mStream->peek() != EOF && strchr(Break, c = mStream->get()) == NULL)
{
if (ToLower)
c = tolower(c);
token += c;
if (trimComments(token)) // don't glue together words separated with comment
break;
}
} while (token == "" && mStream->peek() != EOF); // double check to deal with trailing spaces
edit: jesli masz na mysli, ze bedzie miala miejsce re-alokacja przy
token += c, to wiekszosci mozna uniknac przez dodanie
std::string token = "";
token.reserve(16); // should be enough in most cases
a jeszcze lepiej wrzucic
token do naglowka jako member, i tylko kasowac zawartosc w readToken().
Ogolnie rzecz biorac akurat tutaj wydajnoscia bym sie specjalnie nie przejmowal -- parser jest uzywany glownie do wczytywania konfiguracji podczas ladowania itp, wiec waskim gardlem i tak bedzie przede wszystkim odczyt z dysku.
Co do zajecia sie, nie mam niestety Borlanda wiec raczej nie jestem w stanie -- poprawki musialbym robic "na sucho" bez mozliwosci sprawdzenia czegokolwiek. Ale z tego co widze, to prowizorycznie wystaczyloby dopisac do cParsera:
std::string GetNextSymbol() {
std::string token;
getToken( token );
return token;
}
I tak z 90% istniejacego kodu lyknie zwykla zamiane "TQueryParserComp" na "cParser" (nie bedzie to najbardziej optymalne, ale bedzie dzialac)edit 2: a nie, czekaj, nie bedzie, bo chyba nie masz zamiennikow ToDouble() itp dla zwyklego std::string? czyli i tak trzeba bedzie pozmieniac odwolania do konwersji, bleh.
Pozostale 10% to zmiana wywolan typu
TQueryParserComp *Parser;
Parser = new TQueryParserComp(NULL);
Parser->TextToParse = str;
Parser->First();
na
cParser *Parser;
Parser = new cParser( str );
i juz. Jak sie skompiluje i pojdzie, to wtedy mozna sie bawic w zastapienie istniejacych odwolan do GetNextSymbol() na bardziej eleganckie itp.
Pokaż wiadomości