То есть сборщиком можно управлять?
Частично. Гораздо лучше знать особенности его работы.
Вот неплохая статья на эту тему:
http://www.rsdn.ru/article/dotnet/GC.xmlВ моем примере что-то не нахожу места, где бесконтрольно выделяется память, может подскажешь?
Всё таки оно есть. Вот оно чудо:
- Код: Выделить всё
Public Sub SR_Present()
SetDIBitsToDevice(Graphics.FromHwnd(frmMain.Handle.ToInt32).GetHdc, 0, 0, SR_Width, SR_Height, 0, 0, 0, SR_Height, CBuffer(0), bi32BitInfo, 0)
End Sub
Внутрях сборки System.Drawing в ответ на строку
Graphics.FromHwnd(frmMain.Handle.ToInt32) происходит создание нового обьекта Graphics, а именно вызывается эта функция:
- Код: Выделить всё
<DllImport("gdiplus.dll", CharSet:=CharSet.Unicode, SetLastError:=True, ExactSpelling:=True)> _
Friend Shared Function GdipCreateFromHWND(ByVal hwnd As HandleRef, <Out> ByRef graphics As IntPtr) As Integer
End Function
А так как ссылка на обьект нигде не сохраняется, то сборщик мусора всё это дело пытается похерить(что он с успехом и делал). На лицо бесполезная работа.
Ещё одно место, где шла потеря производительности, в процедуре Render:
- Код: Выделить всё
SR_ClearZBuffer(10000)
SR_ClearCBuffer(&H3F5566)
Вместо этих строк вписал напрямую циклы заполнения массивов.
Итог:
330 fpsНо самое интересное дальше.
На работе стоит Intel Core(TM) 2CPU 4400@2GHz (т.е практически идентичный моему домашнему)
Операционка таже(WinXP Pro SP2)
до исправления твоего кода - 300-311 fps
после исправления твоего кода - 425-436 fps.
Я честно говоря не думал, что Intel так уделает AMD в вычислениях с плавающей точкой.
Завтра на работе погоняю коды VB6 и .Net на другой (64-х битной) машине под Win2003Server.
Проекты сделаны под 2008-ой студией, но под Framework 2.0.
2005-ая к сожалению на днях слетела, а переустановить руки не доходят.