Dear EFL developers,
TL;DR I'd like to merge my work on cserve2 into EFL master soon. This is a commit-flood warning mail. I hope the lucky of you folks who attended EFL dev day 2013 had fun there. Also I hope this was a productive event and you got the opportunity to discuss various EFL-related topics. Amongst those, I trust Cedric made an awesome presentation about cserve2, and introduced the work I've put on top of what had already been done :-) Now is about time to merge this work into the master branch, as it's reached a state where it is (almost?) fast & stable enough to be used to run E18. For those who forgot or could not attend, let me summarize what this is all about: Evas cserve2 is a caching mechanism for Evas images and font (glyphs) that is based on a client-server model. A program, evas_cserve2, runs as a server on the system, waits for commands on a UNIX socket, and loads image files, image data and font data in memory. The memory is then shared and exposed in virtual files in /dev/shm and all applications can access it. This means multiple apps will reuse the exact same resources in memory, and won't need to duplicate common elements such as font glyphs and theme image data. When I first started working on cserve2, it was in an experimentally working state. That is, it worked pretty well in some situations, but there were huge performance bottlenecks, that made it impractical to use in production. One of the main bottlenecks was the massive amount of IPC involved in just opening & loading an image. (Example: client A sends a message to cserve2 to OPEN an image, then waits for cserve2 to answer. cserve2 sends a message to its slave to OPEN that image, receives a message from the slave when it's done, sends a message back to the client A, ... So far the data itself is still not even loaded, and client A will have to request the data in a second message to cserve2...) In particular, most scaling was done on the server and not on the client side, which means that lots of scaled images could be cached even when used only once. So, I worked on reducing unnecessary IPC and optimizing data loading, in two ways: - Reuse the scalecache logic for scaled images (cache only images that would otherwise hit the scalecache, scale on the fly all the rest) - Implement a shared indexing system, where cserve2 exposes its internal cache structure to all the clients. The clients can then scan the indexes (also stored in /dev/shm), bypass part of the heavy IPC and directly open the data. This works very well for images as they will not change at all after being fully loaded. In terms of stability, I've also improved the following: - Support the GL engine (very basic support right now) - Support some exotic stuff (eg. animated Gif) - Allow cserve2 to crash without affecting clients (as long as the system restarts the server) The overall objective of cserve2 is to reduce memory usage at the system level, as applications will share more resources. Also, we can integrate in the future with E, so that the required resources are loaded ASAP when an app starts (predict what an app needs before even it has requested them). So there is a potential performance increase as well, on slower devices at least. I've been actually using it for a couple days and it's surprisingly quite stable ^^. I will fix bugs as they come [1]. The source code is available in my dev branch (rebased on top of master): https://git.enlightenment.org/core/efl.git/log/?h=devs/jpeg/cserve2 It's a LOT of commits, so out of question that I push them without previous notice & discussion :-) As usual, if there's any bug left, blame Cedric. Best regards, [1] I know (only) one bug right now, but shhhhh, don't tell... -- Jean-Philippe André (jpeg) ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel