Сообщение Re[6]: Потоки, net, потеря производительности от 12.02.2015 1:32
Изменено 12.02.2015 1:36 inevity
Здравствуйте, cures, Вы писали:
C>Здравствуйте, inevity, Вы писали:
I>>легко https://yadi.sk/d/Wj_8k3H-ea6Qd
C>Ох! Смешались в кучу кони, люди, и залпы тысячи орудий...
АХАХАХ! Да уж, это чистая правда! Да и писал код по вечерам, даже если что и мог сделать — уже даже этого не мог сделать нормально.
Вообще, сначала написал код, а потом подумал о потоках, опять пришлось притягивать за уши... Плюс результат нужен был быстрее, вот и получилось "я его слепила из того, что было".
C>Если я понимаю правильно, основная работа должна происходить в makesession? Особых вычислений там не заметил (они тщательно замаскированы?), а вот new там хватает. Хип наверняка общий, за него идёт конкуренция.
C>Дельфи у меня нет, это то, что бросается в глаза.
Да, основная работа там. New — я не знал какой функционал потребуется в будущем, и все делал через классы(которые я мог выделить логически). Затем на классы наворачивал функции и прочее.
Я и подумать не мог, что тут кроется проблема...
C>Ещё подозрительны DoEvents, там возможно повторное вхождение в эти функции? Лучше бы логику UI и логику вычислений разнести, потоки по завершении могут дёргать UI колбэки для обновления состояния. Впрочем, об этом Вам там уже написали, Вы ответили, что влиять не должно.
DoEvents я уже сделал вообще "в тупую", т.к. после завершения потоков производительность не нужна вообще и никаких критических мест нет.
C>Для более тщательного анализа лучше бы выделить главную вычислительную часть отдельно и тестировать вообще без UI.
По-хорошему вообще надо было все делать не так... Но, надеюсь, профайлер поможет обнаружить проблему без переделывания кода.
C>Здравствуйте, inevity, Вы писали:
I>>легко https://yadi.sk/d/Wj_8k3H-ea6Qd
C>Ох! Смешались в кучу кони, люди, и залпы тысячи орудий...
АХАХАХ! Да уж, это чистая правда! Да и писал код по вечерам, даже если что и мог сделать — уже даже этого не мог сделать нормально.
Вообще, сначала написал код, а потом подумал о потоках, опять пришлось притягивать за уши... Плюс результат нужен был быстрее, вот и получилось "я его слепила из того, что было".
C>Если я понимаю правильно, основная работа должна происходить в makesession? Особых вычислений там не заметил (они тщательно замаскированы?), а вот new там хватает. Хип наверняка общий, за него идёт конкуренция.
C>Дельфи у меня нет, это то, что бросается в глаза.
Да, основная работа там. New — я не знал какой функционал потребуется в будущем, и все делал через классы(которые я мог выделить логически). Затем на классы наворачивал функции и прочее.
Я и подумать не мог, что тут кроется проблема...
C>Ещё подозрительны DoEvents, там возможно повторное вхождение в эти функции? Лучше бы логику UI и логику вычислений разнести, потоки по завершении могут дёргать UI колбэки для обновления состояния. Впрочем, об этом Вам там уже написали, Вы ответили, что влиять не должно.
DoEvents я уже сделал вообще "в тупую", т.к. после завершения потоков производительность не нужна вообще и никаких критических мест нет.
C>Для более тщательного анализа лучше бы выделить главную вычислительную часть отдельно и тестировать вообще без UI.
По-хорошему вообще надо было все делать не так... Но, надеюсь, профайлер поможет обнаружить проблему без переделывания кода.
Здравствуйте, cures, Вы писали:
C>Ох! Смешались в кучу кони, люди, и залпы тысячи орудий...
АХАХАХ! Да уж, это чистая правда! Да и писал код по вечерам, даже если что и мог сделать — уже даже этого не мог сделать нормально.
Вообще, сначала написал код, а потом подумал о потоках, опять пришлось притягивать за уши... Плюс результат нужен был быстрее, вот и получилось "я его слепила из того, что было".
C>Если я понимаю правильно, основная работа должна происходить в makesession? Особых вычислений там не заметил (они тщательно замаскированы?), а вот new там хватает. Хип наверняка общий, за него идёт конкуренция.
C>Дельфи у меня нет, это то, что бросается в глаза.
Да, основная работа там. New — я не знал какой функционал потребуется в будущем, и все делал через классы(которые я мог выделить логически). Затем на классы наворачивал функции и прочее.
Я и подумать не мог, что тут кроется проблема...
C>Ещё подозрительны DoEvents, там возможно повторное вхождение в эти функции? Лучше бы логику UI и логику вычислений разнести, потоки по завершении могут дёргать UI колбэки для обновления состояния. Впрочем, об этом Вам там уже написали, Вы ответили, что влиять не должно.
DoEvents я уже сделал вообще "в тупую", т.к. после завершения потоков производительность не нужна вообще и никаких критических мест нет.
C>Для более тщательного анализа лучше бы выделить главную вычислительную часть отдельно и тестировать вообще без UI.
По-хорошему вообще надо было все делать не так... Но, надеюсь, профайлер поможет обнаружить проблему без переделывания кода.
C>Ох! Смешались в кучу кони, люди, и залпы тысячи орудий...
АХАХАХ! Да уж, это чистая правда! Да и писал код по вечерам, даже если что и мог сделать — уже даже этого не мог сделать нормально.
Вообще, сначала написал код, а потом подумал о потоках, опять пришлось притягивать за уши... Плюс результат нужен был быстрее, вот и получилось "я его слепила из того, что было".
C>Если я понимаю правильно, основная работа должна происходить в makesession? Особых вычислений там не заметил (они тщательно замаскированы?), а вот new там хватает. Хип наверняка общий, за него идёт конкуренция.
C>Дельфи у меня нет, это то, что бросается в глаза.
Да, основная работа там. New — я не знал какой функционал потребуется в будущем, и все делал через классы(которые я мог выделить логически). Затем на классы наворачивал функции и прочее.
Я и подумать не мог, что тут кроется проблема...
C>Ещё подозрительны DoEvents, там возможно повторное вхождение в эти функции? Лучше бы логику UI и логику вычислений разнести, потоки по завершении могут дёргать UI колбэки для обновления состояния. Впрочем, об этом Вам там уже написали, Вы ответили, что влиять не должно.
DoEvents я уже сделал вообще "в тупую", т.к. после завершения потоков производительность не нужна вообще и никаких критических мест нет.
C>Для более тщательного анализа лучше бы выделить главную вычислительную часть отдельно и тестировать вообще без UI.
По-хорошему вообще надо было все делать не так... Но, надеюсь, профайлер поможет обнаружить проблему без переделывания кода.