Cache growth with parseString

[chrisgraham]

parseString uses a dummy last modified time, which is okay on face value because cache signatures are based on actual rules and contexts. However the last modified time exists through the rule tree, so leaks through to the cache signature. Hence every time parseString is used, there's a new cache file.

I tested changing to something constant and unique. I don't think uniqueness was actually required, as this isn't the cache signature, but doesn't hurt performance much. It's a hack though. Maybe null would have been better, but then it would likely need knock-on changes so that null was always properly handled as a valid value.

diff --git a/flwg.com.au/sources_custom/ILess/Parser/Core.php b/flwg.com.au/sources_custom/ILess/Parser/Core.php
index 6a0e2f2..26392ca 100644
--- a/flwg.com.au/sources_custom/ILess/Parser/Core.php
+++ b/flwg.com.au/sources_custom/ILess/Parser/Core.php
@@ -157,7 +157,7 @@ class ILess_Parser_Core
         // create a dummy information, since we are not parsing a real file,
         // but a string comming from outside
         $this->env->setCurrentFile($filename);
-        $importedFile = new ILess_ImportedFile($key, $string, time());
+        $importedFile = new ILess_ImportedFile($key, $string, crc32($string));

         // save information, so the exceptions can handle errors in the string
         // and source map is generated for the string

Oh and fix spelling of 'coming' too, lol.

In the process of writing this up, I double checked myself, and I'm despairing a bit for 2 reasons...

1. The cache signature is based on rules ($this->rules in Parser.php), so clearly in order to take out of the cache, parsing is needed. Seems the cache is not cacheing as much as it should. A crc32 or md5 of the actual code might be better. I haven't studied in detail, but it really seems inefficient to me.
2. $this->rules is mega-bloated. This may be related to Improve speed of parsing #2. Basically the same set of rules is there 1249 times with me, likely the same combinatorial explosion related to mixins.

[mishal]

thanks again for the feedback :)

Yes, the usage of time() does not make sence to me too. Simple md5 should be ok...

to your points:

1. Yes, the cache works like this, I'm not sure why I did it like this - I will check it.
2. Can you provide more info for this?

[chrisgraham]

Re 2...

Essentially it has the same lump of CSS/LESS(?) repeating again and again in the cache file. I didn't study the structure explicitly, but try compiling some LESS with a few mixins, and then inspect $this->rules to see exactly what is there, I think you'll see. My cache file was around 7MB.

[chrisgraham]

I think actually the cache file size isn't related to the other slowness problem in #2.

I think it's just currentFileInfo is being set throughout the node structure. I think you should at least consider passing this around and into structures as an explicit reference. I think right now it is literally copying the data when the cache is serialized.

[mishal]

The cache system needs an update as you suggested in 1) and 2)

thanks