15.07.2016, 17:30
(
Last edited by Yashas; 15/07/2016 at 06:16 PM.
)
Quote:
|
Originally Posted by Kar
 Theres nothing wrong with this concept, ALOT of scripts out there still use dini, people can just include this instead of dini and speed up their file functions.
Everything must be criticized in this place.. lmao. |
Of course, you will always find me (most of the times) critizing someone because the replies I make which appreciate are very few. I simply don't reply "Good" "Cool" , etc. Sometimes I throw away few reps to satisfy the author if he even cares about them. For Gammix, it might appear that I keep critizing him too often. It is because Gammix keeps releasing something every day and I find faults with it everytime and I just critize it so that it gets improved. Maybe I critize in a mean way or maybe I should change the way I critize. That is what others have to tell rather than complaining that everything is critized in the forums.
Quote:
|
Originally Posted by Gammix
Y_INI vs. eINI vs. DINI2
If the benchmarks are wrong, you may share yours or correct them, i haven't really used Y_INI or any INI processor. Benchmarks code: pawn Code:
Code:
[15:59:11] [Y_INI] Write string to 10 fields 100000 times -> 2944 ms [15:59:19] [Y_INI] Read string from 10 fields 100000 times -> 8173 ms [15:59:20] [eINI] Write string to 10 fields 100000 times -> 965 ms [15:59:21] [eINI] Read string from 10 fields 100000 times -> 838 ms [15:59:21] [DINI2] Write string to 10 fields 100000 times -> 833 ms [15:59:22] [DINI2] Read string from 10 fields 100000 times -> 870 ms |
2. You just wrote the worst possible code for both YINI and eINI. Both these processors provide section id system which cuts down the speed significantly. Maybe even 10x faster with section ids.
3. Your speed tests don't consider opening/writing time at all. In fact, eINI is slower than YINI while parsing given the fact that eINI provides lot of customizable options, it has to be slow. However, the range of features it provides will circumvent the speed loss. In fact, eINI writes and reads faster which compensates for the speed loss while opening the file.
4. YINI and eINI provide dynamic loading system which will just throw your system out of the competition.
5. eINI provides keyid system too which if used could be even 20x faster than YINI but that would be cheating because not everybody knows how to use it and most people would not use it. So the mainstream competition should remain within normal Read/Write functions but there should be at least reasonable optimizations.
If you were to implement those features in your Improved DINI. You can't even call it improved DINI. It would simply be a new INI processor.
I can't do proper speed test so all my new speed claims in this reply are mere guesses.
At first the situation was, gini was slow and did not have enough features. Even though you called it an update for dini it wasn't still worth it. People had to switch to SQL or a new INI processor. Now with your str(un)pack removed, gini meets eINI and YINI when the worst possible code of eINI and YINI is used.
Frankly, I don't want to hurt your feelings but you have too much ego. You are don't like critizisim for some reason. Sometimes you keep arguing about the same thing again and again in spite of best efforts of many to convience you.
I just saw a post where Crayder said the very same thing which I had already told you at least 5 times with big explaination that "you CANNOT add prints/formats/etc inside speed test code". With your logic I can prove that dini is as fast as eINI. I will add 100000 printfs inside the speed test loop and prove that eINI takes 1000ms and dini takes 1001ms so they are almost the same. You say that everytime there has to be code inside becaz its practical but that is not true with speed tests.
If you add just one/two printf inside the command, you will find that ZCMD comes close to IZCMD and you may even conclude that they are the same.
In fact, all performance optimizations loose their meaning if you do speed tests that way beause every optimization will appear to be negligible.
If you still don't know why, get a course on debugging & testing. I am not sure if you are a teen or doing your engineering in CS but anyway the best thing for you right now is to check testing docs and procedures.