Сообщение Re: Производительность FileStream'а от 21.07.2015 4:43
Изменено 21.07.2015 6:14 BulatZiganshin
Здравствуйте, syomin, Вы писали:
S>1. Время обработки файла практически не зависит от того, где расположен обрабатываемый файл: на SDD и HDD. В обоих случаях время одно и то же.
во-первых, файл после первой же обработки кешируется и лежит в озу. так что считай, у тебя filestream читает данные из гигабайтного буфера в озу
S>2. Если сделать обработку файлов в 2 потока, то время обработки уменьшается в 1,5 раза. И по прежнему не зависит от того, где он расположен (SDD или HDD).
вся обработка сводится к тому чтобы скопировать 38 байт в памяти, выполнить какие-то операции над ними и повторить снова. поэтому чем больше потоков cpu ты используешь, тем быстрее это будет
замечу что даже при работе с озу последовательный доступ куда быстрее параллельного. наиболее быстрое решение твоей задачи имхо состоит в том чтобы в первом проходе разбить файл на N частей по диапазону GUID, а затем обработать каждую часть в памяти, отсортировав её. так ты избежишь произвольного доступа к ОЗУ
S>1. Время обработки файла практически не зависит от того, где расположен обрабатываемый файл: на SDD и HDD. В обоих случаях время одно и то же.
во-первых, файл после первой же обработки кешируется и лежит в озу. так что считай, у тебя filestream читает данные из гигабайтного буфера в озу
S>2. Если сделать обработку файлов в 2 потока, то время обработки уменьшается в 1,5 раза. И по прежнему не зависит от того, где он расположен (SDD или HDD).
вся обработка сводится к тому чтобы скопировать 38 байт в памяти, выполнить какие-то операции над ними и повторить снова. поэтому чем больше потоков cpu ты используешь, тем быстрее это будет
замечу что даже при работе с озу последовательный доступ куда быстрее параллельного. наиболее быстрое решение твоей задачи имхо состоит в том чтобы в первом проходе разбить файл на N частей по диапазону GUID, а затем обработать каждую часть в памяти, отсортировав её. так ты избежишь произвольного доступа к ОЗУ
Здравствуйте, syomin, Вы писали:
S>1. Время обработки файла практически не зависит от того, где расположен обрабатываемый файл: на SDD и HDD. В обоих случаях время одно и то же.
во-первых, файл после первой же обработки кешируется и лежит в озу. так что считай, у тебя filestream читает данные из гигабайтного буфера в озу
S>2. Если сделать обработку файлов в 2 потока, то время обработки уменьшается в 1,5 раза. И по прежнему не зависит от того, где он расположен (SDD или HDD).
вся обработка сводится к тому чтобы скопировать 38 байт в памяти, выполнить какие-то операции над ними и повторить снова. поэтому чем больше потоков cpu ты используешь, тем быстрее это будет
замечу что даже при работе с озу последовательный доступ куда быстрее параллельного. наиболее быстрое решение твоей задачи имхо состоит в том чтобы в первом проходе разбить файл на N частей по диапазону GUID, а затем обработать каждую часть в памяти, отсортировав её. так ты избежишь произвольного доступа к ОЗУ
алтернативный вариант — разбить файл на N частей, отсортировать их и записать на диск, затем выполнить N-путёвое слияние
S>1. Время обработки файла практически не зависит от того, где расположен обрабатываемый файл: на SDD и HDD. В обоих случаях время одно и то же.
во-первых, файл после первой же обработки кешируется и лежит в озу. так что считай, у тебя filestream читает данные из гигабайтного буфера в озу
S>2. Если сделать обработку файлов в 2 потока, то время обработки уменьшается в 1,5 раза. И по прежнему не зависит от того, где он расположен (SDD или HDD).
вся обработка сводится к тому чтобы скопировать 38 байт в памяти, выполнить какие-то операции над ними и повторить снова. поэтому чем больше потоков cpu ты используешь, тем быстрее это будет
замечу что даже при работе с озу последовательный доступ куда быстрее параллельного. наиболее быстрое решение твоей задачи имхо состоит в том чтобы в первом проходе разбить файл на N частей по диапазону GUID, а затем обработать каждую часть в памяти, отсортировав её. так ты избежишь произвольного доступа к ОЗУ
алтернативный вариант — разбить файл на N частей, отсортировать их и записать на диск, затем выполнить N-путёвое слияние