5 ms·

Good luck with that , Django code is massive , and when 1 line of python ~= 5 lines of C++ , without all the sugar, the task is not worth it at all. Let alone a

by camus 13y ago

Good luck with that , Django code is massive , and when 1 line of python ~= 5 lines of C++ , without all the sugar, the task is not worth it at all. Let alone all the QA and porting all the legacy code ,which will never be full compatible with a pure C++ implementation unless you know pretty well Python internals. If you need high performance servers,move to the JVM(Scala) or Go,or use a C++ framework , problem solved. Use the right tool for the job.Disqus did and it works pretty well for them , without having to reinvent the wheel.

nostrademons 13y ago
You don't have to port all of it, though. Since you can run Python code from inside C++, you could just use the built-in Python interpreter to run Django, the existing codebase. The only part that really needs to be ported is URL dispatching and Request/Response objects, because that's the interface to the views. The rest could all be done incrementally, replacing components as necessary to gain performance wins. Templates seem like a good candidate because they're used everywhere and would be on the fast path even for C++ code. You'd have to convert all the tags over to get any useful speedup. But you could leave filters in Python and call into them via Python runtime, then convert them over incrementally. I'd do middleware next as that runs on almost all requests. Again, you can do it incrementally: all you need to do on the first pass is a C++ dispatch layer that reads the classes from settings.py and invokes them through the Python interpreter. Change that to let you register & define C++ classes implementing the interface, and you can transition the most common middleware classes one by one to C++. A bunch of stuff I'd expect would never move over to C++. There's no real reason to port django-admin/manage.py, or the admin site. I personally wouldn't care about moving the ORM over; if I want performance I don't use an ORM, and there's nothing wrong with using raw MySQL or libpq calls. A lot of the niche stuff like File Uploads or PDF generation occurs infrequently enough that there's really not much benefit to porting it over. It's debatable whether even Forms is worth including, since most high-traffic pages would not be ones where you're submitting a rich form.

by camus 13y ago

nostrademons 13y ago

You don't have to port all of it, though. Since you can run Python code from inside C++, you could just use the built-in Python interpreter to run Django, the existing codebase. The only part that really needs to be ported is URL dispatching and Request/Response objects, because that's the interface to the views. The rest could all be done incrementally, replacing components as necessary to gain performance wins. Templates seem like a good candidate because they're used everywhere and would be on the fast path even for C++ code. You'd have to convert all the tags over to get any useful speedup. But you could leave filters in Python and call into them via Python runtime, then convert them over incrementally. I'd do middleware next as that runs on almost all requests. Again, you can do it incrementally: all you need to do on the first pass is a C++ dispatch layer that reads the classes from settings.py and invokes them through the Python interpreter. Change that to let you register & define C++ classes implementing the interface, and you can transition the most common middleware classes one by one to C++. A bunch of stuff I'd expect would never move over to C++. There's no real reason to port django-admin/manage.py, or the admin site. I personally wouldn't care about moving the ORM over; if I want performance I don't use an ORM, and there's nothing wrong with using raw MySQL or libpq calls. A lot of the niche stuff like File Uploads or PDF generation occurs infrequently enough that there's really not much benefit to porting it over. It's debatable whether even Forms is worth including, since most high-traffic pages would not be ones where you're submitting a rich form.