read and write to txt file on server - mIRC Discussion Forums

hi i whant to read and write to a file on a server
it should be writing and reading a nick / kicklist

if that is possible one more question... what is the maxsize of a txt files..

the nicklist maybe 25.000 rows long is that possible to do?

greetz

/writeini does not have a "-ds" switch, you got confused with the /write command.

Try this

Code:

 on *:TEXT:!addquote*:#: {
  if ($nick isvoice #) &amp;&amp; ( $3 ) {
    writeini quotes.ini $2-
    msg $chan Quote was added. $+([,$2,:,$3-,]) 
  }
}
on *:TEXT:!quote*:#: {
  if ($nick isvoice #) {
    if (!$readini(quotes.ini, Nicks, $2)) { 
      .notice $nick I'm sorry but there are no quotes for this user. 
    }
    else msg $chan $2 $+ : ( $+ $readini(quotes.ini,Nicks,$2) $+ ) 
  }
}

Syntax:

!addquote <nick> <quote>
!quote <nick>

For more info:

/help /writeini
/help $readini

lol thanks for the help but wrong topic

and i did get those mixed up sorry.
P.S
it didnt work forgot the nicks

Code:

 writeini quotes.ini Nicks $2-
    msg $chan Quote was added. $+([,$2,:,$3-,]) 
  }
}

works now tho thanks again

To the best of my knowledge, text files are only limited in size by the amount of space available on the drive where they're being stored. However, please note that the bigger the file the longer it takes to process, which is why I use hash tables and just load/save the hash tables as files when necessary. By using hash tables, you get the use of your RAM (which is where the table is stored) in addition to the hard drive storage (via windows memory management). Since hash tables reside in RAM the are a lot faster to access.

I ran a quick test on the access time comparing a text file with 25000 items in it, and a hash table with the same number of items. To read the 21,548th item (a randomly selected item) in the text file took 5.6 seconds. To get the same information from the hash table took 0.7 seconds.

Quote:

To get the same information from the hash table took 0.7 seconds.

you sure of that figure? seems a long time for a ram lookup?

the additional delay was due to other items taking up resources on my system...I tried to get as close to a match for resource load when I did each timing....I realize that 0.7 seconds is a long time for a RAM lookup, but I didn't feel like stopping the other processes that I had going when I checked the timing. It was basically just to show the difference in time required for RAM vs. hard drive, under the same circumstances.

Did you use $hget or $hfind? If with $hfind what kind of matching pattern?
There can be huge differences in speed between the two of them, in favour of $hget.

Also did you use $hget(<table>,item) or $hget(<table>,N).item ?
There is a huge difference between those, in favor of $hget(<table>,item)...

Btw, the reason hash tables are as fast as they are, is not only thanks to the fact that they are stored in RAM. Hidden windows with data containing in them are also stored in mem, but with a lot of data, they will lose in speed for writing and reading against hash tables.

Why? I'll try to explain this in a simplistic way...
Because of the way hash tables work, more specifically their lookup methods. When you pass an item to a hash table in order to look up its data, an algorithm is performed on the item (hashing) which transforms the item into a hash, which is a number that the hash table uses to lookup.
You can imagine a hash table storing its data in multiple "buckets" which all contain data.

However, instead of going through each of those buckets to find our specified data, the hash algorithm uses a more efficient way. Based on the hash retrieved after hashing the item, it will know which bucket to look in, bypassing all other buckets.

THIS is what makes hash tables as fast as they are. Their lookup method is not lineair like is the case for text files, .ini files, even hidden windows with data. When looking up a value in a hidden window which has data on each line, the search for a certain line will be lineair, which means line by line, until the result is found. If the data is in the first lines, obviously the retrieval time will be very fast. However imagine the data being in the middle, or even at the end, of a huge database of let's say 50k lines. That will take a very long time.

Not with hash tables, because as said, they simply know which bucket to look into, and bypass all other buckets, so that they find the result much quicker.

Ok that was a very simplified explanation, but it gets the point accross, without getting too technical.

The point of my demonstration was to show that hash tables are faster than text files and to give the person an idea as to how much faster they are.

Eh?

I see a discussion about the speed of hash tables, and not once is the word "hashing" brought up. That seemed fishy to me. I suppose many know how to use hash tables, and are somewhat aware of how it works, but are clueless as to why they are fast for retrieval of data.

From your post I deduced you were from that category. Sure you know it is stored in RAM, but as I stated in my previous post, so are hidden windows, and they are still slower than hash tables.

Point of my post was to clarify some things about why exactly hash tables are fast. Being stored in RAM is, as mentioned, just one of the reasons.

The fact that hash tables use a non-lineair search approach is atleast as important as the fact that they are stored in ram.