Dumping an array in a valid PHP format to file

[133794m3r]

I cannot seem to find a simple/easy way of doing this with one simple command. var_dump, var_export, and other things literally print the data in it's format but do not make the code that comes out valid. It seems as though, i'm going to have to write my own parser for this part of the data dump too since there doesn't seem to be an exact representation of this for it too. The only other option seems to be doing it as a json_encode() but that seems rather pointless since it'd add additional overhead.

[Marek]

A few weeks ago I compared the speed of importing data methods. It turns out that importing a JSON file is FASTER than including native PHP literal data.

The reason is probably because PHP has to parse the included file, and that introduces overhead because the parser is complex. The JSON parser, on the other hand, is really simple and very fast, since it doesn't have to deal with a big language.

There are also the serialize() and unserialize() functions, which I think are similar in speed to JSON. But JSON has the advantage of being implemented in a lot of other languages, so if you ever need to import or export your data somewhere else, it's very easy.

If you still need the PHP method, use var_export() but enclose the data to make it valid PHP: you need to add "<?php $var =" before the var_export string, and a semicolon after it. If you put that in a file and include it, your data will show up in $var.

But I would stick to json_encode / json_decode OR serialize / unserialize. They're the best suited for the job.

[Nox]

I second this

In case of PHP - keep in mind that the core and libraries are written in C, therefore very fast, in most cases faster than your own similar solution in PHP, and in this case - as nano measured - parsing faster then running through the interpreter

Similarly I read than it's pointless to cache the result of parse_ini_file since it's so fast it brings at most close to no improvement

[133794m3r]

i was planning on taking out of the data from the constant data database and then making my own file with said data in it, and making it a sort of function which is called with the index, and what data is needed. And about the reading of the data, that would be native PHP code, the first part just about actually writing it into PHP code. I wasn't talking about writing my own parser for PHP itself but rather writing a program that'd dump the data into PHP associative arrays so that the data could be found faster. The reading then, would be done exactly as if i had manually hard-coded it but this is just automating the process so that i can reduce the number of queries against the database.

[Nox]

We understood this... and I guess the answers still stay

What you intend is a file cache in some sort of format, another is for example memcache(d), apc cache...

[133794m3r]

We understood this... and I guess the answers still stay

What you intend is a file cache in some sort of format, another is for example memcache(d), apc cache...

no.... i actually plan on 'building' it so to speak. As in for example i have an items database. I was going to later on, once it's ready to go, take the results from the database and put them into a code file. Then the engien would use that. That file won't be a 'cache' so to speak of the DB files. It'll only be changed once every week/patch day. The file itself is used to reduce queries. It's not going to be a cache since caches expire, and thus they're rebuilt on the fly. This'll be as if i had hardcoded it all. E.g.

Code: [Select]

$items=Array('id'=>Array(0,1,2),'name'=>Array('nothing','something','bleep'),'lvl'=>Array(10,13,1),'value'=>Array(0,1,10));
that's what I was talking about when I was speaking of it. It converts the database code into the actual code files. The reason for this is because if i have the tools like i do, i can have others working on creating items and not have to have them literally having to work in the databases or hard code everything. Hard coding=faster script executions, and the database stored items=faster creation of content. It's a win-win as i see it.

that'd be included in a file called items.php or something similar and it'd be part of a function which'll call the various things that a person needs.

[Nox]

Let's play with words... you actually said that your files do expire, with frequency about a week/patch interval. "System to reduce queries"... "cache" is defined as a storage (of precomputed or duplicate data) with faster access than the original storage... just like your case.

Whether it's native code or some other format is just a way of formatting the data, it just alters the way how the system receives them, but the content stays the same... if you really want native code, use var_export() as mentioned, otherwise you can use json_encode or whatever else

Or I'm unsure what you actually dislike about the mentioned solutions, how should we think about the problem/what is currently the problem then

[JGadrow]

Actually, you listed the function that does exactly what you requested. I suggest you check out var_export() if you really end up needing this functionality. It does display the variable in PHP syntax. And you can make it return a string (rather than directly outputting) by forcing the 2nd paramter to TRUE.

[133794m3r]

i guess it is a cache of sorts but it's not what i mostly consider a cache so to speak since for me caches expire seconds,minutes maybe hours after the fact. And i guess i forgot to set it to true then and now it's finally working as i thought but it's all non-minimized and such but i guess i can fix that later on by just running it sans white space.

The idea of it as a serialized string, or a json encoded variable seems slower than it being an actual array since it has to first convert it into native php code then it has to actually be able to use it but this other way is just it being itself and working like normal.

The above solutions would work except the fact that i'm attempting to squeeze every last optimization out of the interpreter when it's running.  That's one reason i do ++$i instead of ++$i, and i also use ' instead of " whenever possible along with initializing all of my variables. The other thing is if it's many conditional checks(more than 4) i use switch instead of if else if.

It's all about making the code effecient and every function call that's added onto it whether native, provided via an extension or 'hand rolled' so to speak shouldn't be there along with operators each one adds a bit more time to the code's performance and thus should be avoided like the plague.

[Nox]

I think you're overly concerned about microoptimization. This aproach would be valid rather in case of performance-critical assembler coding or something ... except maybe in case of huge cycles that have 10000+ iterations

I'd rather focus on robust, quality, well-readable code, dry, kiss, maintainability, good application design and content rather then on 0.000 000 02s gains... not that it's necessarily bad, but only as long as it doesn't increase coding time (which ' imho does a lot) and decrease readability etc.

The thing you speak about as "should be avoided like plague" - you mean don't do md($a).substr($x,5) but $c.$d? ... did you do any tests? I'd bet the difference is barely measurable outside large cycles

Plus switch is actually slower, every test I seen and the one I ran now proves that (1M iter, 15 cases, 10 runs - if-else always faster)

Maybe I grown too negligent about this, but then I'd say we're both extremes and it should be somewhere in the middle

[Chris]

"Hard coding=faster script executions, and the database stored items=faster creation of content. " I'm not sure it is always true, especially for longer arrays like items... Definition of items in database works well because almost each time you need an item you need to query individual item, so JOIN of player's item + item definition is natural and simplifies code.

I agree with what Nox said.

It is not C or asm, an attempt to squeeze every tiny bit of optimization in interpreted language is futile. Better use of your time would be reading about database optimization.

[133794m3r]

i've already read up on database optimization and i believe it was chris who was speaking of in another thread of mine that database calls shouldn't be done for the formulas anyway. Also with items and such and queries in general, i believe that you're always someone who was constantly saying "avoid queries as much as possible."

And they do matter since it's a tiny bit faster. I already know that it's negligible but negligible improvements scale up to become worthwhile in the future. My code already is DRY, i go for native instead of reinventing, and i try to make each function do one thing only. And most of the things that i've seen have increased the speed by ~0.00001 seconds at the smallest for the execution on average and that does scale up. It's not making my code take any longer to do since it's standard for  me to type ++$i instead of $i++, same thing with ' vs " it's already been done previously and thus is about the same.

Now as far as hard coded file vs query, i don't know why it'd be that much worse since supposedly queries are one of the deaths of a system, since on this machine it's like 30 queries per second, which means only like 60 people can be doing an insert query every second. lookups are ~2.5k/s with the smaller ones i have and the larger ones are ~2k/s. And everyone speaks about how slow DB lookups are and how horrible they are so why shouldn't i make the things a hard coded like mechanism?

[Chris]

i believe that you're always someone who was constantly saying "avoid queries as much as possible."

True. But that is for optimization advices. Don't forget that the optimization is not the goal, but means. If you have 10 players and don't plan on getting more reducing queries is plain stupid for example Of course I always assume that people who ask for stuff aim to get many players so it is irrelevant, still you have to keep that in mind, optimization is just a tool.

I already know that it's negligible

That's blasphemy, you put optimization in the position of being worshipped. Your "god" is players fun/more players/money, not optimization. Optimization is just an insignificant servant of these. When you put optimization above these or equal to these it is heresy Instead of doing neglible optimization thou shall spend the time on making the game more fun for players. Doing optimization for the sake of optimization is a sinful perversion.

[133794m3r]

i believe that you're always someone who was constantly saying "avoid queries as much as possible."

True. But that is for optimization advices. Don't forget that the optimization is not the goal, but means. If you have 10 players and don't plan on getting more reducing queries is plain stupid for example Of course I always assume that people who ask for stuff aim to get many players so it is irrelevant, still you have to keep that in mind, optimization is just a tool.

I already know that it's negligible

That's blasphemy, you put optimization in the position of being worshipped. Your "god" is players fun/more players/money, not optimization. Optimization is just an insignificant servant of these. When you put optimization above these or equal to these it is heresy Instead of doing neglible optimization thou shall spend the time on making the game more fun for players. Doing optimization for the sake of optimization is a sinful perversion.

faster execution of scripts=less latency between player action and player result. Thus these optimizations help the p;ayer to have a better exepreince. I code my codeto be fast so that i can have more players per server so that first and foremost i can go slightly longer before upgrades and also secondly once it reaches the critical mass point those players can enjoy a less laggy game.

Thusly, it then helps the game to feel faster and keep it going better.

[Chris]

faster execution of scripts=less latency between player action and player result.

By script you mean server side language, like PHP, right? If yes then it is completely irrelevant, network connection will be several times slower than even the slowest script. There is no way human can notice a slow script (because way before it reaches the human noticeable value the server will crash due to rapid resource consumption).

players can enjoy a less laggy game.

I don't see much connection here, never my games were laggy because of PHP. Read the "PHP vs DB" topic, there is a collection of peoples experience regarding this matter.

[133794m3r]

faster execution of scripts=less latency between player action and player result.

By script you mean server side language, like PHP, right? If yes then it is completely irrelevant, network connection will be several times slower than even the slowest script. There is no way human can notice a slow script (because way before it reaches the human noticeable value the server will crash due to rapid resource consumption).

players can enjoy a less laggy game.

I don't see much connection here, never my games were laggy because of PHP. Read the "PHP vs DB" topic, there is a collection of peoples experience regarding this matter.

less database queries=faster game. So the faster that scripts are able to run, along with less queries will make it more efficient. PHP is pretty fast and i know that it's not going to be as fast as native code, but reducing database queries will/should make it run faster.  Once more complex AI scripts have to run during battles the execution of things will be a bit slower.  And i know that the slowest part of the system is going to be its database system. So that's one reason why i'm reducing it right now.

[Chris]

less database queries=faster game.

No... it's not like that, at least not exactly like that. When DB starts slowing down a bit it turn into snowball effect. More and more resources are consumed, more and more memory is being reserved to keep the growing queue of unprocessed requests and it become slower and the cycle repeat until the server crashes. It's more like you either have blazing fast site or crashed site. Something in the middle (laggy) does not happen. Maybe for multi server architecture like Facebook or Google, but not for single server game.

[Delifisek]

I had too many scripts / sites /solutions using with var_export. Using with opcode cache it runs fast. Also you have to develop some kind of driver about this kind of data which supports var_export and memcache. If your game successull later or sooner you will need expand your game multiple servers...

For this kind of web programs, role of SQL server are cheap atomic lock...