| Вопрос: time and Date | Добавлено: 01.06.06 17:23 |
Автор вопроса:  mr_Frank | Web-сайт: subaru.nv-avto.ru | ICQ: 316417 |
| Ответы | Всего ответов: 41 |
|
Номер ответа: 31 Автор ответа:  EROS Вопросов: 58 Ответов: 4255  |
Профиль | | #31 | Добавлено: 04.06.06 16:12 |
|
вот ты к примеру хрен когда выучишь тот же си или ассемблер, или дельфи
 ))))))))
ты абсолютно прав.. я за них даже браться не буду! ибо мой выбор - VB! И он меня вполне устраивает! Удачи!!! |
||
|
Номер ответа: 32 Автор ответа: K&M ICQ: 225442067 Вопросов: 20 Ответов: 170 |
Профиль | | #32 | Добавлено: 05.06.06 23:36 |
| Что за глупости? Если бросать .NET, то я с удовольствием предложу идею кинуть всю винду... И АПИ её... Почему HOOLIGAN решил, что люди попробовавшие .NET никогда не смогут писать под чем нибудь другим? Я начал с .NET, закончил ассемблером. Сейчас я осознаю .NET как инструмент для быстрого развёртывания проэкта, он годится для решения большинства задач. И я бы с удовольствием писал и наслаждался бы тысячами строк быстрейшего и эффективнейшего кода на АСМ, если бы у меня было столько много времени на их написание, только и всего... | ||
|
Номер ответа: 33 Автор ответа: HOOLIGANВопросов: 0 Ответов: 1066 |
Профиль | | #33 | Добавлено: 06.06.06 00:58 |
| я уже писал о пугающих "тысячах строк". Если ты не знаешь того, что асм-исходники могут быть такими же компактными, как и любой другой hls-исходник, то твои слова о том, что ты "закончил ассмеблером" далеки от реальности. | ||
|
Номер ответа: 34 Автор ответа: K&MICQ: 225442067 Вопросов: 20 Ответов: 170 |
Профиль | | #34 | Добавлено: 06.06.06 13:50 |
| Могут... Но не всегда... | ||
|
Номер ответа: 35 Автор ответа: HOOLIGANВопросов: 0 Ответов: 1066 |
Профиль | | #35 | Добавлено: 09.06.06 00:54 |
|
Тут был некий тест (цикл на 50 ходов):
----- Results of call ----- API Test - 0,7833 ms DateTime.Now Test - 0,1391 ms Date.Now Test - 0,0639 ms С GetLocalTime соревноваться не захотели Весовая категория не та...
ОК, может тогда хотя бы "тормознутый" VB6 попытаетесь догнать? В родной msvbvm60 есть две родные встроеные vb-функции: rtcGetTimeBstr и rtcGetDateBstr. Выводят соответственно строку со временем и с датой. На цикл в 50 ходов: rtcGetTimeBstr test - 0.0655 ms rtcGetDateBstr test - 0.0557 ms Это тест на чистом vb, никаких си, асм и т.д. |
||
|
Номер ответа: 36 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #36 | Добавлено: 11.06.06 22:09 |
|
С GetLocalTime соревноваться не захотели
Весовая категория не та...Что значит не захотели??? Если ты немного шире откроешь глазки, то ты увидишь в том тесте кусок кода.. '//API Test
stopWatch.Start() For Counter = 1 To 50 Dim LocalTime As SYSTEMTIME GetLocalTime(LocalTime) Next stopWatch.Stop() Console.WriteLine("API Test - {0} ms", stopWatch.Elapsed.TotalMilliseconds) stopWatch.Reset() Угадай с 1 раза, какая API здесь вызывалась для тестирования в среде .NET? И результат "некоего теста" как Вы изволили выразиться относится именно к этой API. И результат тестирования я предоставил.. И тест проводился только для того, чтобы ты наконец-то понял, что не стоит пыжиться с этими АПИ в НЕТ, потому что родные ф-ии работают здесь на порядок быстрее!!! Поскольку вопрос был задан в НЕТ-форуме, то и тестирование проводилось в среде НЕТ.. и чего ради ты в этом форуме приводишь результаты тестирования на VB6?? Неужели ты так и не понял, что в НЕТ эти АПИ как мертвому припарка!! Ты их на VB-шном форуме впаривай и говори,что это кульно!!! Там это еще имеет смысл.. а в НЕТ они, это только тормоза, не более того.... |
||
|
Номер ответа: 37 Автор ответа: HOOLIGANВопросов: 0 Ответов: 1066 |
Профиль | | #37 | Добавлено: 11.06.06 22:24 |
|
апи - это отдельный разговор, с этим уже разобрались - .нет тормозит безбожно при их вызове.
в последнем посте я говорил о том, что vb-функции быстрее, чем .нет-функции, а ты чего-то на апи накинулся
Я тебя призываю вернуться на vb, пока не поздно, а то совсем пропадешь в нете. )))
|
||
|
Номер ответа: 38 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #38 | Добавлено: 11.06.06 23:01 |
|
апи - это отдельный разговор
ты знаешь.. заметил странную особенность при тестировании.. вот смотри результат 3 тестовых запусков по 50 вызовов: ----- Results of call -----
GetLocalTime Test - 0,7277 ms DateTime.Now Test - 0,1388 ms Date.Now Test - 0,0639 ms ----- Results of call ----- GetLocalTime Test - 0,3204 ms DateTime.Now Test - 0,0762 ms Date.Now Test - 0,0636 ms ----- Results of call ----- GetLocalTime Test - 0,3251 ms DateTime.Now Test - 0,0768 ms Date.Now Test - 0,0631 ms я не знаю чем это объяснить, но при втором и последующих вызовах результаты сильно отличаются от первого ... Я тебя призываю вернуться на vb, пока не поздно, а то совсем пропадешь в нете.
)))))))
Я,разумеется, признателен за твою заботу, но неужели ты и правда думаешь,что всю простоту и удобство НЕТ я променяю ради сотых долей миллисекунды выигрыша во времени исполнения??? да ни закие коврижки!! Если уж и придется переходить на что-то с НЕТ, то это явно будет не 6-ка.. )) а что нибудь посерьезнее и менее убогое(тот же Си или асм) Но пока (тьфу-тьфу) у меня в этом необходимости не возникало.. НЕТ полностью удовлетворяет моим потребностям.. ))
|
||
|
Номер ответа: 39 Автор ответа: HOOLIGANВопросов: 0 Ответов: 1066 |
Профиль | | #39 | Добавлено: 12.06.06 01:17 |
|
Вообще тестирование на скорость такими способами не делается (циклы, вызовы Timer, watch и т.д.) Но в силу отсутствия возможности применять нормальные методы приходится довольствоваться...
А при тестировании всегда повторные результаты будут иметь лучшие показатели. В силу того, что существует кэш, в котором сохраняется код и данные, учавствующие в тесте. И при повторном вызове не тратится время на их подгрузку в кэш. Нормальный тест делается при помощи Performance Counter как минимум, а лучше используя счетчик процессора (инструкция rdtsc). Первый проход позволяет оценить время на загрузку и выполнение кода, а устоявшиеся показатели (обычно 5 и далее проходы) позволяют оценить оптимальность тестируемого алгоритма как такового. Для операций, в реальном приложении выполняющихся разово, более важен первый показатель, для выполняющихся многократно в циклах - второго. Есть ещё масса факторов, влияющих на эту разницу, но в основном это то, что описано выше. |
||
|
Номер ответа: 40 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #40 | Добавлено: 12.06.06 13:03 |
| В .NET есть возможность юзать Performance Counter, надо будет разобраться с ним на досуге, а то все как то руки не доходили.. | ||
|
Номер ответа: 41 Автор ответа: Sacred PhoenixICQ: 304238252 Вопросов: 52 Ответов: 927 |
Профиль | | #41 | Добавлено: 23.06.06 20:15 |
|
я не знаю чем это объяснить, но при втором и последующих вызовах результаты сильно отличаются от первого ...
При компиляции проги код компилируется не полностью. Эту заботу о докомпиляции берет на себя тот же .net framework при первом обращении к функции/методу и т.п. при последующих обращениях вызываются уже полностью скомпилированные функции, поэтому они и вызываются на порядок быстрее. Мелкомягкие обещали, что в сл. версиях vb.net докомпилировать прогу придется один раз - при первом запуске проги, а не при каждом. |
||