Hi Sven,
Right, but you want to push miniprofiler further down the app than that.
For example, with datomic I have a yeller.datomic.instrumented namespace
that exports the same vars as datomic.api, but wraps them in miniprofiler
tracing. From the point of view of my application code, the only thing that
changes is that you require a different namespace, which is significantly
easier than littering trace calls everywhere.
Does that help?
Tom
On Sunday, 8 February 2015 08:57:12 UTC, Sven Richter wrote:
>
> Hi Tom,
>
> I am not arguing about the performance impact here, however, it's nice to
> know there hardly is one. My only concern is that the code reader has to
> mentally parse away the trace calls, which puts a small burden on him and
> which might be less if it was in some kind of a macro, fn or metadata.
> However, I am still a clojure beginner and this was just one thing that
> came to my mind when I saw it :-)
>
> Thanks,
> Sven
>
> Am Samstag, 7. Februar 2015 22:16:04 UTC+1 schrieb tcrayford:
>>
>> Hi Sven,
>>
>> So typically I'd put that stuff *much* lower in the database layer -
>> ideally as a wrapper around whatever database driver you're using, but that
>> kind of idea is roughly right.
>>
>> I am considering releasing a set of libraries for miniprofiler that let
>> it wrap e.g. a jdbc driver, redis clients, and so on. This is a clear case
>> where having an interface or a protocol at the low level of the database
>> driver really helps. That way you'd just import the library, tell it to
>> wrap the connection and use it yourself. Would that be useful? Which
>> database are you using?
>>
>> When miniprofiler isn't on, it has pretty minimal performance impact
>> (apart from the fact that you're adding more code to your methods which can
>> have implications for the JIT) - it's just a binding load and a nil? check,
>> which is pretty quick. I leave that code in production for my app, and have
>> done since July.
>>
>> Pushing the profiling information as low in the stack as possible, and
>> leaving it on in production is a powerful combination - typically you never
>> think about profiling or tracing whilst writing your code, but it's always
>> there, even in production where you need it.
>>
>> Hope that helps,
>>
>> Tom
>>
>> On Saturday, 7 February 2015 08:21:31 UTC, Sven Richter wrote:
>>>
>>> Hi,
>>>
>>> I just tried it and it looks really useful if one wants to track down
>>> speed bumps in web apps.
>>>
>>> I wonder if I understand the usege correctly, right now I did something
>>> like this:
>>>
>>> (defn admin-page [params]
>>> (let [users (cjmp/trace "all users" (db/get-all-users (get params
>>> :filter)))]
>>> (layout/render "user/admin.html" (merge {:users users :roles
>>> available-roles}
>>> params))))
>>>
>>>
>>> I think this blows the code and one has to remove / add the trace
>>> function everytime one wants to profile the code.
>>> Maybe it would be an improvement if one could add some metadata to
>>> functions which then would be profiled only in dev mode for example?
>>>
>>> Best Regards,
>>> Sven
>>>
>>>
>>> Am Mittwoch, 4. Februar 2015 14:21:28 UTC+1 schrieb tcrayford:
>>>>
>>>> Ack, minor date error there.
>>>>
>>>> I've been running Clojure Miniprofiler in production since July 2014,
>>>> and it's proved both very stable, and extremely useful.
>>>>
>>>> On Wednesday, 4 February 2015 13:16:43 UTC, tcrayford wrote:
>>>>>
>>>>> Clojure Miniprofiler is a simple, but effective profiling tool for
>>>>> your web application.
>>>>>
>>>>> It tells you what is slow about a web page both in production (for
>>>>> admins only), and in development, as you load the page.
>>>>>
>>>>> It's a port of the original .Net library to Clojure, utilizing the
>>>>> JavaScript and UI code that was originally written there.
>>>>>
>>>>> Read more about it here:
>>>>>
>>>>> http://yellerapp.com/opensource/clojure-miniprofiler.html
>>>>>
>>>>> And a sample performance debugging session is detailed here:
>>>>>
>>>>> http://yellerapp.com/posts/2015-02-04-miniprofiler.html
>>>>>
>>>>> I've been running Clojure Miniprofiler in production since July 2015,
>>>>> and it's proved both very stable, and extremely useful.
>>>>>
>>>>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
