The fastest way to log (at least) DDLs, which will have the least performance impact would be using the binary log. It is stored in a binary format and written to the file system cache by default, so it does not add extra synchronous flush operations to disk. Typical overheads are around 5%, and this can be less if you use 5.6's binlog group commit, filtering at master level or playing around with the 2 main binlog formats (even in row mode, DDLs are stored in statement format). You can transform the binlogs into human-readable logs with the utility mysqlbinlog.
The problem with the binlog is that it doesn't trace usernames and hosts, so it may be useless for your purposes. In any case, activating the binary logs is almost always a good idea.
I think the best option here would be an audit plugin, as you are basically trying to do that (auditing queries and users). There are several options available, and you can even program one yourself, but I like the McAfee audit plugin, which is free, open-source and good enough for this case. Here it is a brief review on how to use it. You can configure it to monitor "drop"s (and/or any other command). This should be less costly than activating the general log (and more convenient), but I have not benchmarked it myself. It can log to a file or to a UNIX socket in json format. This is a sample output: