| Вопрос: Оптимизация кода для быстродействия (массивы) | Добавлено: 05.03.08 02:59 |
Автор вопроса:  traford
|
| Ответы | Всего ответов: 63 |
|
Номер ответа: 31 Автор ответа:  s12 Вопросов: 24 Ответов: 363 |
Профиль | Цитата | #31 | Добавлено: 16.03.08 04:26 |
|
попробуй выкинуть дотнет и написать на Си++
Я полностью согласен с HACKER'ом.
.Net не очень то быстро работает со строками и о нормальной скорости работы программы остается только мечтать, тем более с такими огромными текстовыми файлами. Как альтернативу С++ , можно порекомендовать PureBasic или FreeBasic.
Например: код на FreeBasic: #include once "windows.bi"
dim s as string dim i as double dim ar as string dim start as long start=GetTickCount open "s.txt" for input as #1 s="" print "loading..." do while not eof(1) input #1, s loop print "load OK ", GetTickCount-start sleep Выполняется 26 секунд. (Celeron1.6 +винт Sata2 5600 об/мин.), размер s.txt 110 Мб. |
||
|
Номер ответа: 32 Автор ответа: Artyom Разработчик Вопросов: 130 Ответов: 6602 |
Профиль | Цитата | #32 | Добавлено: 16.03.08 04:29 |
|
arr = File.ReadAllLines(FI.FullName)
Блин, о чем-то говорили на двух страницах и к чему пришли? К тому же с чего начинали. Ладно, надоело. |
||
|
Номер ответа: 33 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | Цитата | #33 | Добавлено: 16.03.08 04:37 |
|
.Net не очень то быстро работает со строками и о нормальной скорости работы программы остается только мечтать
Где это он не быстро работает со строками? Можешь обосновать? Выполняется 26 секунд. (Celeron1.6 +винт Sata2 5600 об/мин.), размер s.txt 110 Мб.
Комп дрова, конечно, но посмотри на предыдущую страницу, у меня 500-мегабайтовый файл обрабатывается за 9 секунд. Т.е. в 13 раз быстрее чем у тебя в рассчете на единицу объема. Пусть это и грубо - у меня комп быстрее - Intel Core 2 Duo E6750, диск SATA2 7200 кажется. Вообще о возможностях IO классического BASIC скромно промолчу. |
||
|
Номер ответа: 34 Автор ответа: s12Вопросов: 24 Ответов: 363 |
Профиль | Цитата | #34 | Добавлено: 16.03.08 04:54 |
|
Ну гм..
Вообще о возможностях IO классического BASIC скромно промолчу
Free Basic никаким местом к нему не относится... Комп дрова, конечно, но посмотри на предыдущую страницу, у меня 500-мегабайтовый файл обрабатывается за 9 секунд.
№%&, повезло тебе с машиной. у меня этот код выполняется около 4 минут. сейчас попробую его на fb переписать и посмотрю, действительно ли я глупость написал
|
||
|
Номер ответа: 35 Автор ответа: s12Вопросов: 24 Ответов: 363 |
Профиль | Цитата | #35 | Добавлено: 16.03.08 05:06 |
|
#include once "windows.bi"
dim s as string dim i as double dim ar as string dim start as long start=GetTickCount open "s.txt" for input as #1 i=0 print "loading..." do while not eof(1) s="" input #1, s i=i+1 loop print i print GetTickCount-start sleep Выполняется 128 сек. против 202 на .NET Хотя чистым этот результат тоже назвать нельзя, vb работает в CLR, это медленее чем прямое обращение к диску. |
||
|
Номер ответа: 36 Автор ответа: s12Вопросов: 24 Ответов: 363 |
Профиль | Цитата | #36 | Добавлено: 16.03.08 16:28 |
|
#include once "windows.bi"
#include "crt/stdio.bi" dim s as zstring ptr dim i as double, t as long dim ar as string dim start as long Dim f As FILE Ptr start=GetTickCount f = fopen("s.txt", "r" 
t=0 print "loading..." While feof(f) = 0 i = fgetc(f) if i=10 then i=fgetc(f) if i=13 then t+=1 end if Wend print t print GetTickCount-start sleep А вот этот кусок 64 сек. |
||
|
Номер ответа: 37 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | Цитата | #37 | Добавлено: 16.03.08 21:47 |
|
vb работает в CLR, это медленее чем прямое обращение к диску
Сейчас тебя сожрут. |
||
|
Номер ответа: 38 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | Цитата | #38 | Добавлено: 16.03.08 21:52 |
|
Вообще о возможностях IO классического BASIC скромно промолчу
Free Basic никаким местом к нему не относится... OPEN/CLOSE/INPUT/... - это классические IO-костыли BASIC от которых в .NET давно отказались в пользу объектной модели. |
||
|
Номер ответа: 39 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | Цитата | #39 | Добавлено: 17.03.08 01:02 |
|
Dim start = DateTime.Now
Const BufLength As Integer = 1024 * 1024  im Buf(BufLength - 1) As Byte
Using FS = New FileStream("e:\pagefile.sys", FileMode.Open) im Length As Integer
o
Length = FS.Read(Buf, 0, BufLength) Loop While Length = BufLength End Using Console.WriteLine(Now.Subtract(start)) Console.ReadLine() Вряд ли можно будет сделать быстрее При сравнении учти что файлы могут кешироваться (у меня, например, первый проход работает около 4 секунд, поседующие - примерно за 0.6-0.4 секунд), поэтому тестирование нужно проводить на достаточно больших файлах. Но вообще на дисковых операциях сравнение проводить смысла я вижу мало - кеши стоят везде - ни самих дисках, как видишь, Windows тоже выполняет кеширование, плюс скорость может сильно зависеть от фрагментации файла и т.п. В любом случае самым узким местом будет быстродействие диска (и всегда так было) Хотя чистым этот результат тоже назвать нельзя, vb работает в CLR, это медленее чем прямое обращение к диску.
Ужос, более сказочного тупизма слышать не приходилось. Как FCL, так и твой FreeBasic, обращаются к диску через функции ОС. К чему ты тут CLR упомянул вообще не ясно, ты хоть сказать что CLR работает медленнее диска? |
||
|
Номер ответа: 40 Автор ответа: s12Вопросов: 24 Ответов: 363 |
Профиль | Цитата | #40 | Добавлено: 17.03.08 01:08 |
|
OPEN/CLOSE/INPUT/... - это классические IO-костыли BASIC от которых в .NET давно отказались в пользу объектной модели.
Объектная модель оно конечно очень хорошо.. но не всегда. В последнее время очень много развелось технологий с применением виртуальных машин (VM)
Сначала заявила о себе Java, потом .NET. 1С:Предприятие тоже работает через промежуточный код. Попала ко мне система программирования FBIde с FBC - FreeBasicCompiler. Я думал, что это очередная реализация языка Бейсик, но оказалось не совсем так: По принципу работы его можно слабо сравнить с дотнетом. Приложения на выходе получаются очень маленькие (15-25КБ). Поддерживает ООП! Было бы отлично, если бы с прогами не нужно было таскать более чем 100 МБ библиотек! Почему новые технологии все больше и больше переходят на байт-код, интерпретацию, VM? Разве это удобнее? Кстати, fbc генерит ассемблерные коды БЕЗ МУСОРА из данных, и к тому же нормально читаемые, то есть секциями типа .text ... FreeBasic не использует VM, он нативный и по количеству платформ на которых способен пахать переплевывает FPC.. Так что, по идеи на нем драйвера писать можно. Asm-всавки тоже поддерживает. Хотя насколько он состоялся в проффесиональном плане (ну там оптимизаияm баги компилера), это уже хз.. Мы сравниваем ломик и отмычку, назначение вроде одно, а вот исполнение
Я ничего против VB.NET не имею (нихарашо кусать лапу которая тебя кормит), просто утверждаю что FB наиболее подходящий для выполнения именно этой конкретной задачи. |
||
|
Номер ответа: 41 Автор ответа: s12Вопросов: 24 Ответов: 363 |
Профиль | Цитата | #41 | Добавлено: 17.03.08 01:27 |
|
Ужос, более сказочного тупизма слышать не приходилось.
Да, выразился немного не так, CLR тоже отъедает приличный кусок как оперативки, так и процессорного времени (Framework 3.5 вроде получше имхо) Как FCL, так и твой FreeBasic, обращаются к диску через функции ОС
ржунимагу... это уж как приспичит, хошь через ОС, нехошь тогда напрямую к железу можно обратится
Да и FB не мой, его создатель Андрэ Виктор. К чему ты тут CLR упомянул вообще не ясно, ты хоть сказать что CLR работает медленнее диска?
Имелось в виду обращение к диску через CLR. В любом случае самым узким местом будет быстродействие диска (и всегда так было)
Не поспоришь. PS: Пора уже кончать эту флудильню (если ув. Steel Brand не настаивает на сатисфакции), о достоинствах и недостатках языков можно спорить вечно. |
||
|
Номер ответа: 42 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | Цитата | #42 | Добавлено: 17.03.08 01:59 |
|
просто утверждаю что FB наиболее подходящий для выполнения именно этой конкретной задачи.
Чем он наиболее подходящий? Да, выразился немного не так, CLR тоже отъедает приличный кусок как оперативки, так и процессорного времени
Ты какие-то тесты проводил? Можешь пояснить свои слова? (Framework 3.5 вроде получше имхо)
Могу тебя заверить, .NET Framework 3.5 отличается от .NET Framework 2.0 и .NET Framework 3.0 только наличием новых сборок и нового компилятора, среда исполнения осталась та же и базовые системные сборки не изменились. ржунимагу... это уж как приспичит, хошь через ОС, нехошь тогда напрямую к железу можно обратится
Покажи примерчик, забавно будет на это посмотреть. Имелось в виду обращение к диску через CLR.
Обращение к диску идет через Win32API. Если ты запустишь Reflector то сможешь понять что непосредственное чтение выполняется функцией ReadFile. Разумеется, на вызов трех промежуточных функций тратится некоторое количество тактов, собственно, оно тратится и в варианте с Free Basic, и ничтожно мало по сравнению с тем сколько времени идет собственно чтение данных с диска. Мы не ведем речь о достоинствах и недостатках (глупо сравнивать язык который стал одним из стандартов в современной индустрии разработки с наколенной поделкой). |
||
|
Номер ответа: 43 Автор ответа: s12Вопросов: 24 Ответов: 363 |
Профиль | Цитата | #43 | Добавлено: 17.03.08 03:58 |
|
Покажи примерчик, забавно будет на это посмотреть.
Прошу: #include once "windows.bi"
Dim Filehandle As Integer Dim txt As String dim start as long start=GetTickCount On Error Goto HandleErrors dim t as long Filehandle = FreeFile t=0 Open "s.txt" For binary access read As #filehandle while EOF(filehandle) = 0 Line Input #filehandle, txt t+=1 wend print txt Close #filehandle Print t print "Time= ", GetTickCount-start sleep HandleErrors: print "Error." Работа с диском идет в "обход" ОС (неверующим SoftIce в зубы и впеёед, товарисци, тока впеёд . Есть более чистый вариант, там работа с файлом осуществляется через дискриптор, нет времени рисовать сей увлекательный момент (да и низковато это уже получается).
Могу тебя заверить, .NET Framework 3.5 отличается от .NET Framework 2.0 и .NET Framework 3.0 только наличием новых сборок и нового компилятора, среда исполнения осталась та же и базовые системные сборки не изменились.
Надо внимательнее читать, я и говорю что под 3.5 исполняемые файлы "похудели" Обращение к диску идет через Win32API. Если ты запустишь Reflector то сможешь понять что непосредственное чтение выполняется функцией ReadFile.
Разумеется, на вызов трех промежуточных функций тратится некоторое количество тактов, собственно, оно тратится и в варианте с Free Basic, и ничтожно мало по сравнению с тем сколько времени идет собственно чтение данных с диска. Гут. Тогда на кой бес вообще нужен Framework, если все реализуется через старые добрые API??? Ты какие-то тесты проводил? Можешь пояснить свои слова?
Оч. смешно.За что ругали Java когда он появился? Так ли уж сильно .NET отличается от Java (и в лучшую ли сторону)?
Мы не ведем речь о достоинствах и недостатках (глупо сравнивать язык который стал одним из стандартов в современной индустрии разработки с наколенной поделкой.
Очень качественная поделка. Был бы у нее IDE и появись она лет на 10 раньше... |
||
|
Номер ответа: 44 Автор ответа: s12Вопросов: 24 Ответов: 363 |
Профиль | Цитата | #44 | Добавлено: 17.03.08 04:30 |
|
просто утверждаю что FB наиболее подходящий для выполнения именно этой конкретной задачи.
Чем он наиболее подходящий? 1.В приведенном выше примере время обработки у меня чуть меньше 12 сек. 2.Для выполнения не требуется сторонних библиотек (тока Win32Api) как минус: достаточно сложно сделать графический интерфейс "под Windows" |
||
|
Номер ответа: 45 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | Цитата | #45 | Добавлено: 17.03.08 05:07 |
|
С твоими кодами одни проблемы - ни один из них не захотел работать с файлом в 2 ГБ.
Надо внимательнее читать, я и говорю что под 3.5 исполняемые файлы "похудели"
Поясни каким образом они могли "похудеть" если системные сборки, JIT-компилятор и CLR остались такими же? Гут. Тогда на кой бес вообще нужен Framework, если все реализуется через старые добрые API???
Попробуй сравнить код чтения файла через FCL и через АПИ. Оч. смешно.За что ругали Java когда он появился?
И за что например? Причем тут .NET? Нафига с темы съезжаешь? Так ли уж сильно .NET отличается от Java (и в лучшую ли сторону)?
Определенно да. Очень качественная поделка. Был бы у нее IDE и появись она лет на 10 раньше...
смешно 1.В приведенном выше примере время обработки у меня чуть меньше 12 сек.
Я бы привел время для сравнения, но твой код получается запустить только на очень маленьких файлах (десятки КБ), на больших файлах он моментально завершает свою работу, показывая время 0 и длину файла 0, подозреваю что происходит какая-то ошибка, которая некорректным образом обрабатывается (попросту, как в классическом BASIC, "глушится" поэтмоу мы и не имеем никакого результата.
(Vb .NET на тех же файлах прекрасно работает, через проводник они доступны, т.е. проблема не в правах доступа) 2.Для выполнения не требуется сторонних библиотек (тока Win32Api)
Для выполнения кода .NET не требуется сторонних бибилотеки (только FCL) Можешь почитать изначальный вопрос - речь идет об обработке строк, что классически не является сильной стороной BASIC (в VB .NET ситуация куда лучше) |
||