\nWhen you want to optimize a program, you first need to know\nwhere the time is being spent.\nThere’s no point optimizing a function that isn’t actually\nresponsible for your poor performance.\nFor example, if a particular function is responsible for 2% of\nyour CPU time, then even if you optimized it down to infinite speed,\nyour program would speed up at best by only little over 2%.\nIn the comments to yesterday’s entry, several people put forth\nsuggestions as to how the program could be optimized,\nin the process quite amply demonstrating this principle.\nNone of the people who made suggestions actually investigated\nthe program to see where the glaring bottleneck was.\n<\/p>\n
\n(Rico Mariani<\/a> points out that you also\nneed to take performance in account when doing high level designs,\nchoosing algorithms and data structures that are suitable for\nthe level of performance you need.\nIf profiling reveals that a fundamental design decision\nis responsible for a performance bottleneck, you’re in big trouble.\nYou will see this sort of performance-guided design as the program develops.\nAnd you should check out\n\nPerformance Quiz #6<\/a>\nwhich starts with the very program we’re developing here.)\n<\/p>\n \nUpon profiling our dictionary-loader, I discovered that\n80% of the CPU time was spent in \nDigging a little deeper, it turns out that\n29% of the CPU time was spent by \nLet’s get rid of the piecemeal character set conversion and\ninstead convert entire lines at a time.\n<\/p>\n \nInstead of using a \nWe ask code page 950 for a converter, which we call \nFor each line that isn’t a comment, we convert it to Unicode.\nOur lives are complicated by the fact that \nWith this tweak, the program now loads the dictionary in 1120ms\n(or 1180ms if you include the time it takes to destroy the\ndictionary). That’s nearly twice as fast as the previous version.<\/p>\ngetline<\/code>.\nClearly this is where the focus needs to be.\nEverything else is just noise.\n<\/p>\ngetline<\/code> doing\ncharacter set conversion in codecvt::do_in<\/code>.\nSome debugging revealed that codecvt::do_in<\/code>\nwas being called millions of times, each time converting\njust one or two characters. In fact, for each character\nin the file, codecvt::do_in<\/code> was called once\nand sometimes twice!\n<\/p>\n\nDictionary::Dictionary()\n{\n std::ifstream<\/font> src;\n typedef std::codecvt<wchar_t, char, mbstate_t> widecvt;\n std::locale l(\".950\");\n const widecvt& cvt = _USE(l, widecvt); \/\/ use_facet<widecvt>(l);<\/font>\n src.open(\"cedict.b5\");\n string<\/font> s;\n while (getline(src, s)) {\n if (s.length() > 0 && s[0] != L'#') {\n wchar_t* buf = new wchar_t[s.length()];\n mbstate_t state = 0;\n char* nextsrc;\n wchar_t* nextto;\n if (cvt.in(state, s.data(), s.data() + s.length(), nextsrc,\n buf, buf + s.length(), nextto) == widecvt::ok) {\n wstring line(buf, nextto - buf);<\/font>\n DictionaryEntry de;\n if (de.Parse(line<\/font>)) {\n v.push_back(de);\n }\n }\n delete[] buf;<\/font>\n }\n }\n}\n<\/pre>\nwifstream<\/code>,\nwe just use a non-Unicode ifstream<\/code>\nand convert each line to Unicode manually.\nDoing it a line at a time rather than a character at a time,\nwe hope, will be more efficient.\n<\/p>\ncvt<\/code>.\nNotice that the Microsoft C++ compiler requires you to use\nthe strange _USE<\/code> macro instead of the more traditional\nuse_facet<\/code>.\n<\/p>\ncodecvt::in<\/code>\nrequires pointers to elements rather than iterators, which means\nthat we can’t use a wstring<\/code> or a vector<\/code>;\nwe need a plain boring wchar_t[]<\/code> array.\n(Notice that we can cheat on the “from” buffer and use the\nstring::data()<\/code> function to get at a read-only\narray representation of the string.)\nIf the conversion succeeds, we convert the array into a proper\nstring and continue as before.\n<\/p>\n