Intro-CSharp-Book-v2015

Глава 25. Практически изпит по програмиране (тема 2) 1057
}
}
private static void TestCountWords()
{
List testData = GetTestData();
foreach (string testCase in testData)
{
Console.WriteLine("Test Case:{0}{1}",
Environment.NewLine, testCase);
Console.WriteLine("Result:");
CountWords(ExtractWords(testCase));
}
}
Дискусия за производителността
Тъй като въпросът за производителността в тази задача не е явно поставен,
само ще дадем идея как бихме могли да реагираме, ако евентуално се
окаже, че нашият алгоритъм е бавен. Понеже разделянето на текста по
разделящите символи предполага, че целият текст трябва да бъде прочетен
в паметта и думите, получени при разделянето също трябва да се запишат
в паметта, то програмата ще консумира голямо количество памет, ако
входният текст е голям. Например, ако входът е 200 MB текст, програмата
ще изразходва най-малко 800 MB памет, тъй като всяка дума се пази два
пъти по 2 байта за всеки символ.
Ако искаме да избегнем консумацията на голямо количество памет, трябва
да не пазим всички думи едновременно в паметта. Можем да измислим
друг алгоритъм: сканираме текста символ по символ и натрупваме буквите
в някакъв буфер (например StringBuilder). Ако срещнем в даден момент
разделител, то в буфера би трябвало да стои поредната дума. Можем да я
анализираме дали е с малки или главни букви и да зачистим буфера. Това
можем да повтаряме до достигане на края на файла. Изглежда по-ефективно,
нали?
За по-ефективно проверяване за главни/малки букви можем да направим
цикъл по буквите и проверка на всяка буква. Така ще си спестим
преобразуването в горен/долен регистър, което заделя излишно памет за
всяка проверена дума, която след това се освобождава, и в крайна сметка
това отнема процесорно време.
Очевидно второто решение е по-ефективно. Възниква въпросът дали
трябва, след като сме написали първото решение, да го изхвърлим и да
напишем съвсем друго. Всичко зависи от изискванията за ефективност. В
условието на задачата няма предпоставки да смятаме, че ще ни подадат
като вход стотици мегабайти. Следователно сегашното решение, макар и
не оптимално, също е коректно и ще ни свърши работа.