Из ваших комментариев, я не думаю, что вам действительно нужно знать, будет ли объект идти на LOH или нет. Независимо от того, является ли это фактической причиной замедления вашего приложения, это не имеет никакого значения, когда все, что вы действительно хотите сделать, - это отображать предупреждение пользователю, когда они вводят значение, «слишком большое».
Итак, я бы предложил что-то более простое: просто используйте бит проб и ошибок, чтобы определить значение отсечки. Если они вводят размер по сравнению с пробным и ошибочным значением, отобразите предупреждение.
Что касается ваших реальных проблем с производительностью, вместо выделения одного большого двумерного массива вы можете просто выделить кучу «меньших» одномерных массивов. Вместо того, чтобы:
Node[,] n = new Node[100,100]; // this will go the LOH
Вы бы сделать это:
Node[][] n = new Node[100][];
for(int i = 0; i < n.Length; i++) {
n[i] = new Node[100]; // none of these will be on the LOH
}
Вы все еще имеют одинаковое количество узлов в целом, но ничего не будет идти на LOH. Лично я думаю, вы, вероятно, обнаружите, что производительность на самом деле не будет совсем другой, но, возможно, стоит просто попробовать.
Я не считаю, что это возможно (без использования API профилирования). Почему ты хочешь знать? –
У меня проблемы с производительностью с одной структурой, используемой приложением. Я успешно оптимизировал другие массивы (http://stackoverflow.com/questions/2762424/what-is-the-fastest-way-to-initialize-a-multi-dimensional-array-to-non-default-va/) , Тем не менее, эта структура является настоящим убийцей производительности. – AMissico
Если это просто для настройки производительности, то почему бы просто не использовать профилировщик, как вы? –