More memory efficient handling of content

[Gert]

was soll cmsimple eigentlich werden?

Hallo Winni, falsche Frage. Richtig wäre:

"Was soll CMSimple_XH eigentlich werden?"

CMSimple wird bleiben was es ist, mit all seinen Grenzen und Beschränkungen. Natürlich wird immer mal wieder was optimiert werden, aber vorsichtig.

Für die, denen das nicht reicht, gibt es genügend andere CMS,

Gert

[snafu]

was soll cmsimple eigentlich werden?

Hallo Winni, falsche Frage. Richtig wäre:

"Was soll CMSimple_XH eigentlich werden?"

Entschuldige diese sprachliche Ungenauigkeit, da ich hier im cmsimple_XH Forum schreibe und es um zukünftige _xh Versionen geht, ging ich einfach davon aus, das es klar ist, das ich damit das community projekt cmsimple_XH und nicht die cmsimple v4 gemeint habe.

CMSimple wird bleiben was es ist, mit all seinen Grenzen und Beschränkungen. ..... Für die, denen das nicht reicht, gibt es genügend andere CMS

Es gibt halt keine eierlegende Wollmilchsau, die zu realisieren wird auch nicht funktionieren.
Die Last der Wahl des Anwenders, womit er welches Problem lösen kann, kann man am besten dadurch reduzieren, indem man genau die Rahmenbedingungen und Möglichkeiten des eigenen Angebots schildert. Wenn er dann etwas anderes zur Lösung seiner Probleme nimmt, mag man das vielleicht als Verlust betrachten, ist aber allemal besser, als den Stress für alle Beteiligten, wenn er an die Grenzen des Produktes stößt.

[cmb]

Google makes you sound like you didn't like the idea because "if it isn't broken, don't fix it".

Probably google translate is a bit overcharged, when it comes to translate Winni's posts.

Was ihr jetzt versucht ist Flickschusterei. Ein neues Datenmodell, bei dem wohl auch die meisten Plugins gesprengt werden und dann trotzdem krampfhaft an der Dateibasierung festzuhalten? Das macht nicht wirklich Sinn!

Translation:

What you're trying now is tinkering. A new data model, which will blow probably many plugins---but still frantically sticking with flat file storage? That really doesn't make much sense!

I have to agree. AISB: in the long run I'm hoping for a cleaner API (e.g. the mentioned getters and setters), which would make it possible to provide alternative storage models. But we shouldn't rush into that.

I don't care much for the plugins as they may contain many more suprises than the cms itself, of course i could make my own plugins. Not everyone can do that, i agree.

That's exactly the point. I would even say: "most users and webdesigners can't write their own plugins, and even those who could, may not have the time."

Entschuldige diese sprachliche Ungenauigkeit, da ich hier im cmsimple_XH Forum schreibe und es um zukünftige _xh Versionen geht, ging ich einfach davon aus, das es klar ist, das ich damit das community projekt cmsimple_XH und nicht die cmsimple v4 gemeint habe.

Well, it's always possible, that some ideas that are discussed here, might make it to other variants of CMSimple than CMSimple_XH.

Es gibt halt keine eierlegende Wollmilchsau, die zu realisieren wird auch nicht funktionieren.

I agree. "Use the right tool for the job at hand". But suggested improvements should always be considered by carefully weighing the pros and cons. Otherwise a good opportunity to improve the system may be easily missed. "Stagnation is regression", particularly when it comes to IT.

Cmsimple is flawed by "read everything" at one array design at every single request.

IMO CMSimple has more severe flaws, particularly regarding the plugin handling. These may be addressed first.

Well and for me if this never makes into the official version, i'm just better off using the modified slicker core.

You may consider sticking with standard CMSimple_XH, unless actual performance issues arise, in which case you can still switch to an optimized version. And of course the decision, if and when this optimization will be included in CMSimple_XH, is not made. I'm just one of the developers; the others may have quite different opinions.

[eeeno]

I have now done some testing locally and with the modified rfc() provided by cmb, it indeed is a turbocharged version to say at least.

I created dummy content with about 4.5MB data in content-file and with "the traditional way" of doing it it took approx. 68% longer to process than with the supercharged rfc()
With file size of about 18 MB which is just entirely out of this world, i agree, the processing was 401% faster! That may very well be faster than Mysql in a real hosting environment.

The real benefits would surface even with smaller content sizes in a real hosting environment with limited resources. You could really call that a supercharged core.

Well as it would break the compatibility i suggest having a modified, experimental cms.php available for those who know exactly what they are doing. You could employ caching of globals, headings etc in the official version as it won't break things and did result in significantly faster processing times.

I'd really like to see this in the future versions of Cmsimple_xh, well at least experimental optimizations included in a separate "hacked" cms.php.

[cmb]

I created dummy content with about 4.5MB data in content-file and with "the traditional way" of doing it it took approx. 68% longer to process than with the supercharged rfc()
With file size of about 18 MB which is just entirely out of this world, i agree, the processing was 401% faster!

Are these the performance improvements for rfc(), the index.php request or the complete (X)HTML document? I assume the first one; however, the improvement is quite impressive.

Well as it would break the compatibility i suggest having a modified, experimental cms.php available for those who know exactly what they are doing. You could employ caching of globals, headings etc in the official version as it won't break things and did result in significantly faster processing times.

I'd really like to see this in the future versions of Cmsimple_xh, well at least experimental optimizations included in a separate "hacked" cms.php.

I've put it on the roadmap. I'm not convinced, that we should do this for XH 1.6. One one hand the man-power is currently quite small, on the other hand there are changes already made (`marriage' of content.htm and pagedata.php), which might make these improvements less effective and/or harder to implement. If you like, have a look at branches/1.6/ in the SVN on SourceForge.

[cmb]

Hallo Gert,

CMSimple wird bleiben was es ist, mit all seinen Grenzen und Beschränkungen. Natürlich wird immer mal wieder was optimiert werden, aber vorsichtig.

Und warum suchst Du dann einen Sponsor, der es 2 selbsständigen Webdesignern und Programmierern ermöglicht, mindestens halbtags an der weiteren Entwicklung von CMSimple zu arbeiten und vielleicht noch einige gelegentliche Mitstreiter auf Honorarbasis zu bezahlen, hauptsächlich Übersetzer? (von http://cmsimple.org/?Sponsoring___Hauptsponsor_gesucht)



Christoph

[eeeno]

Are these the performance improvements for rfc(), the index.php request or the complete (X)HTML document? I assume the first one; however, the improvement is quite impressive.

It is not only rfc(), it is based on how quick the server running cmsimplexh is to respond after connection is estabilished, in other words how long it took for php to begin outputting xhtml/html code back.

Change is remarkable with bigger content.htm, although it is not very likely that anyone would be using a content file that huge. But in theory the change would be noticeable with smaller content sizes if there was many visitors simultaneously hitting the site with requests. So in theory if one has content.htm of a size of 5MB to 10 MB it'd be no problem for the cms, even at 20MB it'd still be just as quick (or almost) as with a file size of 50kB. (when pagemap cache is available)

[eeeno]

It has indeed been a long time since there was any discussion on this. I checked the roadmap. It has indeed been added to 1.7 version roadmap. I'd be happy to see it in the future versions.
Btw, is this hack now included as a separate file in any release?

[cmb]

Btw, is this hack now included as a separate file in any release?

No, it is not. As you call it, it's a hack, and I don't think it's a good idea to put such hacks directly in the official download. It could be offered as AddOn or something; perhaps an entry in the Wiki would be a good idea.

I'd rather prefer a clean solution, such as the mentioned getters and setters. For CMSimple_XH 1.6 I have implemented the somewhat experimental XH_Pages class. Something like that could be defined as interface (we'll have to wait for interfaces until we drop support for PHP 4)--actually setters would have to be added. If the plugins will be changed to work against this interface, it would be trivially easy to have several alternative implementations of the interface, so the user could choose the one he prefers (content.htm as it's now; an optimized variant with a pagemap; even a database as store).

[eeeno]

I do agree with you completely.

For most small websites it mostly won't be an issue as there's not much content anyway. But it is something to keep in mind for the future. Xh pages looks like a way to go and it's easy to add that hack into it. If there'd be a database then it'd have to be sqllite or some similar "databaseless" solution. I don't know how efficient it is... haven't tried it... yet...