Таблица Таблицы распределения файлов

Question

Я работаю над обычным файловым файловым файлом FAT, и все идет неплохо. Тем не менее, я хочу знать, есть ли лучший способ эффективно читать/писать в цепочку. Для больших устройств это может быть невероятно ресурсоемким, и это может быть очень, очень медленно. Особенно при распределении пространства.

Вот как я прочитал:

public void ReadChainMap() 
    { 
     chainMap = new uint[clusterCount]; 
     fx.Io.SeekTo(chainMapOffset); 
     EndianIo io = new EndianIo(fx.Io.In.ReadBytes((int)chainMapSize), EndianType.BigEndian); 
     io.Open(); 

     for (int x = 0; x < clusterCount; x++) 
      chainMap[x] = (chainMapEntrySize == 2) ? 
       io.In.ReadUInt16() : io.In.ReadUInt32(); 


     io.Close(); 
    } 

Цепь иногда может быть сотни мегабайт.

И вот как я его пишу. Когда выделение и модификация массива chainMap uint выполнены, он будет в основном прокручивать этот массив uint и переписать всю цепочку.

public void WriteChainMap() 
    { 
     EndianIo io = new EndianIo(new byte[chainMapSize], 
      EndianType.BigEndian); 
     io.Open(); io.SeekTo(0); 

     for (int x = 0; x < clusterCount; x++) 
      if (chainMapEntrySize == 2) 
       io.Out.Write((ushort)chainMap[x]); 
      else 
       io.Out.Write(chainMap[x]); 

     fx.Io.SeekTo(chainMapOffset); 
     fx.Io.Out.Write(io.ToArray()); 
    } 

Я работаю над системой кеша, но хочу получить еще несколько идей о том, как сделать это лучше.

Answer 1

Кажется, что вы могли бы сегментировать его каким-то образом. Вместо того, чтобы читать/писать все, «страницы в/из» куски на основе использования. Подумайте о системах виртуальной памяти для вдохновения.

Answer 2

Я провел много исследований и тестирования по двоичной сериализации, и одна вещь, которая поразила меня, заключалась в том, что вы могли быстро прочитать довольно большие блоки с сегодняшними жесткими дисками и что часть льва на самом деле была потрачена на преобразование байтов в целые числа , строки и т. д.

Итак, одна вещь, которую вы можете сделать, это обратная архитектура, чтобы использовать все ваши ядра, сначала прочитайте как можно больший блок данных, а затем используйте PLINQ или Parallel.net, чтобы выполнить фактическую десериализацию. Возможно, вы даже захотите пойти еще дальше в модель производителя/потребителя. Вы увидите только прибыль для большого количества записей или больших блоков или данных, хотя в противном случае это обычно не стоит распараллеливать.

Кроме того, у вас есть инструкция поиска, это всегда дорого, попробуйте использовать файл с памятью или сразу же прочитайте большой блок, если это возможно и применимо.