в файле d.dat содержится 181440 полей. (в дальнейшем надо около 1 триллиона)
вот код, как я ищу нужную строку по заданному ключу m


Время поиска : 920.880383 миллисеунд. Примерно 0.920 секунды

Это УЖАСНО долго на самом деле. нужно не более чем  0.1 секунда.

я думаю что основное время затрачивается на


потому-что каждый раз при исполнении. это выполняется.

вопрос 1: можно ли как-то сразу при компиляции загрузить этот файд d.dat. что бы исполнении его уже не надо было загружать.
вопрос 2: какой есть более эффективный способ хранения информации, что бы затраты(по времени) на поиск нужного значения были сведены к минимуму.

1. А зачем при компиляции? Можно при запуске сразу считывать его, но это будет неоправданно, на мой взгляд, забивать ОП. Особенно, когда там будет триллион записей. А при компиляции - это сразу же создать явно переменную, проинициализированную информацией из d.dat
2. Ну самый быстрый - это в ОП. Из других... может быть БД?

Это сообщение отредактировал(а) shimopus - 9.12.2006, 14:37

Используйте индексирование. При нем, сначало строится оптимизированный файл индекса. А поиск происходит только по нему (индексу). 
Вот вам в помощь Apache Lucene.

как вот это

выполнить сразу при объявлении ht. 
d.dat 6мб, впринцыпе для меня это не критично.
зато скорость 0.360242 миллисеунд. 

Когда-то, лет 12 назад, на первом еще VB я столкнулся с проблемой булева поиска в текстовой БД. На тот момент и память была маленькой и процессор быстро информацию не жевал. Решение было примерно такое:

• Файл был единый, но грузился не целиком, а по блокам, ну, скажем по N строк. 
• Блок грузился и объединялся в сплошной текст с разделительными, текстовыми же, символами. 
• Велся поиск в этой одной огромной "строке". 
• Если нужное не находилось - грузился следующий блок. 
• Записи, естественно, лежали в файле упорядоченно и грузился не первый блок, а блок наиболее вероятно содержащий искомую информацию.  
• При новом поиске сначала обыскивался блок уже лежащий в памяти (все равно уж он там); это часто помогало точнее определить какой блок грузить следующим.

Звучит все это, конечно, дико, но народ приходил ко мне удивляться как быстро эта крокозябра работала.

По моему в данном случае явное непонимание, того как это все должно работать. В данном случае без индекса не обойтись, можно его делать руками, как описал _Y_. Можно использовать готовы решения типа Apache Lucene. А можно просто использовать механизм индексирования СУБД.

P.S. Прикола ради посчитай сколько это 1 триллион записей по 10 байт ;)

Бери FileChanel класс. И 4итай нужное коли4ество байт а не всю строку за раз.

ID 32(bytes)                            stroka(255bytes)
dfmg493t04kdhfgdfh...............Moja.stroka........
893bg8gb43t934t43...............Stoka.nomer.2....

Так вот во время 4теня ты 4итешь 32 байта если ID=запросу ID, to 4итаешь следующие 255 байт. Если не равны то пропускаеш  255 байт fileChanel.position(fileChannel.position()+255).